[Search] [txt|ps|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 04                                                      
            INTERNET DRAFT<draft-labarre-internetmib-iso-04.txt>Expires August, 1994
     
     
     
     
                 ISO/CCITT and Internet Management Coexistence (IIMC):
     
                 Translation of Internet MIBs to ISO/CCITT GDMO MIBs
     
                                   (IIMCIMIBTRANS)
     
     
                                   February, 1994
     
     
                                Lee LaBarre (Editor)
     
                                The MITRE Corporation
                                   Burlington Road
                                  Bedford, MA 01730
                                cel@mbunix.mitre.org
     
     
            Status of this Memo
     
            This document provides information to the network and
            systems management community.  This document is intended as
            a contribution to ongoing work in the area of multi-protocol
            management coexistence and interworking.  This document is
            part of a package; see also [IIMCOMIBTRANS] [IIMCMIB-II]
            [IIMCPROXY] and [IIMCSEC]. Distribution of this document is
            unlimited. Comments should be sent to the Network Management
            Forum IIMC working group (iimc@thumper.bellcore.com).
     
            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 ds.internic.net,
            nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the
            current status of any Internet Draft.
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994              Page i
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
            Abstract
     
            This document is intended to facilitate the multi-protocol
            management coexistence and interworking for networks that
            are managed using the ISO/CCITT Common Management
            Information Protocol (CMIP) and networks that are managed
            using the Internet Simple Network Management Protocol
            (SNMP).  This document contains translation and registration
            procedures that are applicable to translation of Internet
            MIBs, defined according to the Internet Structure of
            Management Information (SMI), into ISO/CCITT SMI-defined
            MIBs.  This document also defines and registers generic
            management information that may be used with the translation
            procedures to facilitate interoperability.
     
            Table of Contents
     
            1. INTRODUCTION ..........................................1
     
               1.1  PROBLEM STATEMENT.................................1
     
               1.2  OVERVIEW OF IIMC..................................2
     
               1.3  MIB TRANSLATION PROCEDURES........................3
     
               1.4  NATIVE MANAGEMENT MODEL...........................3
     
               1.5  PROXY MANAGEMENT MODEL............................5
     
               1.6  SCOPE OF THIS DOCUMENT............................6
     
               1.7  TERMS AND CONVENTIONS.............................7
     
            2. REGISTRATION AND NAMING PROCEDURES ....................8
     
               2.1 REGISTRATION PROCEDURES............................8
                  2.1.1 Automated Registration Procedures ............8
                         2.1.1.1 Translated Object Classes and
                                 Attributes Registration .............9
                         2.1.1.2 Translated NAME BINDINGs
                                 Registration ........................10
                         2.1.1.3 Translated ASN.1 Modules and
                                 Documents Registration ..............10
                         2.1.1.4 Naming Attribute Registration........12
                  2.1.2 IIMC Explicit Registration Procedures ........12
                         2.1.2.1 Explicit ASN.1 Modules and
                                 Documents Registration ..............13
                         2.1.2.2 Explicit Trap/Notification
                                 Registration ........................13
     
               2.2 NAMING PROCEDURES..................................14
                  2.2.1 Naming Attributes ............................14
                  2.2.2 ISO/CCITT-Internet Naming Tree ...............15
     
            LaBarre             Expires August, 1994             Page ii
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                  2.2.3 Distinguished Names ..........................16
     
               2.3 OID TRANSLATION....................................16
                  2.3.1 OID/Name Translation ISO/CCITT to Internet ...16
                  2.3.2 OID/Name Translation Internet to ISO/CCITT ...19
     
               2.4 INHERITANCE FOR OBJECT CLASSES.....................20
     
               2.5 REFERENCE LABELS FOR DERIVED ENTITIES..............21
     
            3. INTERNET TO ISO/CCITT MIB TRANSLATION PROCEDURES ......22
     
               3.1 PRE-TRANSLATION PROCEDURES.........................22
     
               3.2 GDMO TRANSLATION PROCEDURES........................25
                  3.2.1 Translation of Groups ........................25
                  3.2.2 Translation of Table Entry Objects ...........27
                  3.2.3 Translation of Other OBJECT-TYPES ............29
                  3.2.4 Translation of Notifications .................32
                  3.2.5 Log Record for Internet Alarm ................33
                  3.2.6 Translation of Internet Attribute Types ......33
     
               3.3 POST-TRANSLATION PROCEDURES........................36
                  3.3.1 Post-translation of BEHAVIOUR Cause ..........36
                  3.3.2 Creation of NAME BINDING Templates ...........36
                  3.3.3 Attribute Property-label Changes .............41
                  3.3.4 Post-processing of ASN.1 Module ..............41
                  3.3.5 Templates for Naming Attributes ..............42
                  3.3.6 Generation of MOCS ...........................43
     
            4. IIMCIMIBTRANS MIB .....................................44
     
               -- 4.1 IMIBTRANS MIB GDMO TEMPLATES....................44
                  -- 4.1.1 IMIBTRANS Managed Object Classes ..........44
                  -- 4.1.2 IMIBTRANS Attribute Types .................46
                  -- 4.1.3 IMIBTRANS Attributes ......................54
                  -- 4.1.4 IMIBTRANS Notifications ...................55
     
               -- 4.2 IMIBTRANS ASN.1 MODULES.........................57
     
            5. COMPLIANCE AND CONFORMANCE ............................61
     
               5.1 COMPLIANCE.........................................61
     
               5.2 CONFORMANCE........................................61
     
            ANNEX A (NORMATIVE): MANAGED OBJECT CONFORMANCE
               STATEMENTS (MOCS)......................................A-1
     
            ANNEX B: GLOSSARY ........................................B-1
     
            ANNEX C: REFERENCES ......................................C-1
     
     
     
            LaBarre             Expires August, 1994            Page iii
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            List of Figures
     
            FIGURE 1. MIB TRANSLATION ................................3
     
            FIGURE 2. NATIVE MANAGEMENT ..............................4
     
            FIGURE 3. PROXY MANAGEMENT ...............................5
     
     
            List of Tables
     
            TABLE 1. MAPPING THE GROUP ACCESS CLAUSE .................27
     
            TABLE 2. MAPPING THE TABLE ENTRY OBJECT ACCESS CLAUSE ....28
     
            TABLE 3. MAPPING TO MATCHING RULES .......................30
     
            TABLE 4. COMMON ATTRIBUTE TYPES ..........................31
     
     
     
     
     
                                  REVISION HISTORY
     
     
            Issue 1.0, October 1993
     
            This is the first issue of this document. The internet draft
            <draft-labarre-internetmib-iso-04>, dated February, 1994, is
            identical in content to Issue 1.0, October 1993. It has been
            reformatted for posting as an internet draft.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994             Page iv
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
                                   1. INTRODUCTION
     
            This section provides an overview of ISO/CCITT and Internet
            Management Coexistence (IIMC) activities, insight into the
            problem being addressed by IIMC, and a brief introduction to
            the strategy adopted by IIMC: use of translated MIBs in
            either a proxy or native implementation. The section
            concludes by describing the scope of this document, and
            terms and conventions used by this document.
     
     
     
            1.1  PROBLEM STATEMENT
     
            The need for enterprise network management has been
            addressed by development of network management standards
            within various communities, most notably the ISO/CCITT and
            Internet communities.
     
            *  The ISO/CCITT community developed the Common Management
               Information Protocol (CMIP) [5], and related SMI
               documents [7,8,9].
     
            *  The Internet community developed the Simple Network
               Management Protocol (SNMP) [12], and its successor,
               SNMPv2 [19]. The Internet SMI is defined in [11] and
               [17].
     
            These standards share a nearly common management model, but
            diverge due to differing management philosophies. Although
            functionally similar, the Internet and ISO/CCITT protocols
            and SMIs differ in terms of their complexity and specific
            operations. Business requirements for end-to-end enterprise
            management include the need to integrate the management of
            many different devices, potentially owned or administered by
            many independent organizations. This requires components to
            be accessed by ISO/CCITT management, Internet management,
            and proprietary management mechanisms in a manner which
            presents a unified view of the network, despite protocol and
            SMI differences.
     
            For example, many telecommunications and computer vendors,
            represented by organizations such as the Network Management
            Forum (NMF), and the U.S. government, as specified in the
            Government Network Management Profile (GNMP) Version 1.0
            [27], have based their enterprise management model on the
            ISO/CCITT management model. These organizations are
            particularly interested in integrated management of devices
            that use the Internet management. This interest is primarily
            due to the widespread commercial implementation and use of
     
     
            LaBarre             Expires August, 1994              Page 1
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            such devices, especially devices that use the Internet
            TCP/IP protocol suite.
     
     
     
            1.2  OVERVIEW OF IIMC
     
            The ISO/CCITT and Internet Management Coexistence (IIMC)
            package includes the following documents.
     
            IIMCIMIBTRANS  Translation of Internet MIBs to ISO/CCITT
                           GDMO MIBs
     
            IIMCOMIBTRANS  Translation of ISO/CCITT GDMO MIBs to
                           Internet MIBs [25]
     
            IIMCMIB-II     Translation of Internet MIB-II (RFC 1213) to
                           ISO/CCITT GDMO MIB [22]
     
            IIMCPROXY      ISO/CCITT to Internet Management Proxy [23]
     
            IIMCSEC        ISO/CCITT to Internet Management Security[24]
     
            These documents together comprise a package aimed at
            integrating ISO/CCITT-based and Internet-based management
            systems.
     
            IIMC specifications address the problem 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"
            [26]. The documents included in the IIMC package are the
            next level of detailed specifications which implement
            several of the methodologies identified in the strategy.
            Additional specifications may be defined in the future.
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994              Page 2
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            1.3  MIB TRANSLATION PROCEDURES
     
            The foundation of IIMC is provided by a pair of Management
            Information Base (MIB) translation procedures.
     
            *  IIMCIMIBTRANS (this document) specifies translation
               procedures for converting MIBs from Internet MIB macro
               format into ISO/CCITT GDMO template format.
     
            *  IIMCOMIBTRANS [25] specifies translation procedures for
               converting MIBs from ISO/CCITT GDMO template format into
               Internet MIB macro format.
     
            The IIMC approach is to specify direct translation
            procedures which yield a pair of functionally-equivalent
            MIBs, as shown in Figure 1.
     
            +----------------+     +--------------------+     +----------------+
            |  Internet MIB  |     |   MIB Translation  |     |    GDMO MIB    |
            |                |     |     Procedures     |     |                |
            |  Format =      |     |    Specified By    |     | Format =       |
            |  [RFC1212] &   |---->| [IIMCIMIBTRANS] or |---->| [ISO10165-1] & |
            |  [RFC1442]     |<----| [IIMCOMIBTRANS]    |<----| [ISO10165-4]   |
            +----------------+     +--------------------+     +----------------+
     
                             Figure 1. MIB translation.
     
            MIBs translated by these procedures may be used to take
            advantage of existing MIB definitions when business needs
            require deployment in a different management environment.
            Translated MIBs may also be used to provide uniformity when
            multiple management environments are supported by a single
            system (e.g., dual stack managers). Finally, IIMC MIB
            translation procedures may be used to support service
            emulation by a proxy.
     
     
     
            1.4  NATIVE MANAGEMENT MODEL
     
            The basic model for ISO/CCITT and Internet management is
            illustrated in the following diagram.
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994              Page 3
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
                       Manager                               Agent
              +-----------------------+            +----------------------+
              |+---------------------+|            |+-------------------+ |
              ||     Management      ||            ||      Managed      | |
              ||    Applications     ||            ||     Resources     | |
              |+---------------------+|            |+-------------------+ |
              |   |                   |            |    |                 |
              |   |                   |            |    |                 |
              |+-----------+---------+|            |+----------+---------+|
              ||  Manager  |   MIB   ||            ||  Agent   |   MIB   ||
              |+-----------+---------+|            |+----------+---------+|
              |    |                  |            |    |                 |
              |    |  Management      |            |    |  Management     |
              |    |   Services       |            |    |   Services      |
              +-----------------------+            +----------------------+
              |  Management Protocol  |            |  Management Protocol |
              +-----------------------+            +----------------------+
                         ^                                    ^
                         |                                    |
                         +------------------------------------+
                                    Protocol Messages
     
                            Figure 2. Native management.
     
            Within IIMC documents, this model is referred to as the
            "native" management model. MIBs translated using IIMC
            procedures can be used by "native" agent implementations.
            For example, an ISO/CCITT agent can make visible TCP/IP
            managed resources using the translated GDMO version of the
            Internet MIB-II [14] specified by [22]. Dual-stack managers
            or agents may also be implemented which support both the
            original MIB and the translated MIB generated using IIMC-
            specified procedures.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994              Page 4
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            1.5  PROXY MANAGEMENT MODEL
     
            The basic model for ISO/CCITT to Internet proxy management
            is illustrated in the following diagram. This proxy is
            specified by [23]. A similar approach could also be taken to
            specify an Internet to ISO/CCITT proxy, although no such
            IIMC document is currently specified.
     
                      Manager                   Proxy                   Agent
             +-----------------------+  +---------------------+  +------------------
             |+---------------------+|  |+------+ +----------+|  |+-----------------
             ||     Management      ||  || GDMO | | Internet ||  ||      Managed
             ||    Applications     ||  || MIB  | |   MIB    ||  ||     Resources
             |+---------------------+|  |+------+ +----------+|  |+-----------------
             |      |                |  |+-------------------+|  |      |
             |      |                |  ||      Service      ||  |      |
             |      |                |  ||     Emulation     ||  |      |
             |      |                |  ||(scoping)          ||  |      |
             |      |                |  ||  (filtering)      ||  |      |
             |+-----------+---------+|  ||    (operations)   ||  |+----------+------
             || ISO/CCITT |   GDMO  ||  ||  (message         ||  || Internet | Inter
             ||  Manager  |   MIB   ||  ||    transformation)||  ||  Agent   |   MIB
             |+-----------+---------+|  |+-------------------+|  |+----------+------
             |    |                  |  |  |CMIS           |  |  |    |
             |    | CMIS Services    |  |  |Services       |  |  |    | SNMP "Servic
             |    |                  |  |  |               |  |  |    |
             |    |                  |  |  |           SNMP|  |  |    |
             |    |                  |  |  |     "Services"|  |  |    |
             +-----------------------+  +---------------------+  +------------------
             |         CMIP          |  |   CMIP   |   SNMP   |  |        SNMP
             +-----------------------+  +---------------------+  +------------------
                        ^                     ^         ^                   ^
                        |                     |         |                   |
                        +---------------------+         +-------------------+
                             CMIP Messages                  SNMP Messages
     
                             Figure 3. Proxy management.
     
            This ISO/CCITT to Internet proxy 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 IIMCIMIBTRANS. The proxy uses these MIB
            definitions and rules to provide run-time translation of
     
     
            LaBarre             Expires August, 1994              Page 5
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            management information carried in service requests and
            responses.
     
            The proxy 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 CMIP operations, and forwarding/logging of
            CMIS notifications by performing a mapping process which
            must be tailored for each protocol (for example, SNMPv1 and
            SNMPv2 are variants of the same protocol mapping process).
     
     
     
            1.6  SCOPE OF THIS DOCUMENT
     
            A major reason for the rapid commercialization of devices
            manageable via the Internet management protocol is due to
            the speed with which the vendors in the Internet community
            have been able to develop MIBs based on the Internet SMI. To
            capitalize on this continuing Internet MIB development and
            their deployment in commercial devices, communities
            interested in integrated management via ISO/CCITT-Internet
            proxies require that procedures be defined for translation
            of Internet MIBs into ISO/CCITT GDMO MIBs, i.e., MIBs
            defined according to the ISO/CCITT SMI Guidelines for
            Definition of Managed Objects [9]. Communities interested in
            using ISO/CCITT management protocols to directly manage
            resources using the Internet defined MIB elements are also
            interested in MIB translation procedures. Such MIB
            translations may also minimize the independent development
            of ISO/CCITT GDMO MIBs for the same resources and thereby
            reduce the incompatibilities with the Internet MIBs.
     
            Translation procedures which may be automated to a high
            degree, and include unambiguous automated registration
            procedures, are of particular interest to the communities
            interested in using GDMO translations of Internet MIBs. This
            document (IIMCIMIBTRANS) defines such procedures.
     
            This document also defines generic SNMP trap to CMIS
            notification mappings, common naming conventions, and ASN.1
            modules applicable to translated Internet MIBs.
     
            Many of the procedures defined in this document may be
            subject to automation. Comments are provided concerning
            possible aids to automation; however, it is not the intent
            of this document to provide fully automated translation
            algorithms.
     
     
     
     
     
     
            LaBarre             Expires August, 1994              Page 6
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            1.7  TERMS AND CONVENTIONS
     
            This document assumes that the reader is familiar with the
            ISO/CCITT SMI and Internet SMI, and the terminology of each.
            The term SNMP will be used throughout the document to
            indicate either SNMPv1 or SNMPv2, unless a distinction needs
            to be made.
     
            Other conventions used during the translation process are
            described in Section 3.2.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994              Page 7
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
                        2. REGISTRATION AND NAMING PROCEDURES
     
            Registration and naming procedures are crucial to the unique
            identification of management information. Registration
            assures the uniqueness of management information element
            types, while naming provides a way of distinguishing
            instances of a type and locating them within the MIB.
     
     
     
            2.1 REGISTRATION PROCEDURES
     
            The registration authority for management definitions
            produced during the translation process shall be the Network
            Management Forum.
     
             WARNING: Object Identifiers produced during the
                   translation process are only provisionally assigned.
                   The object identifiers are not registered until
                   approved by the registration authority. In cases of
                   conflict with existing registered object identifiers,
                   the registration authority will manually assign
                   object identifiers.
     
            Registration procedures specify that changes in the syntax
            or semantics of registered entities require them to be
            registered as new entities. The process of converting
            Internet MIBs into the ISO/CCITT GDMO MIBs inevitably
            introduces subtle semantic changes in how data can be
            operated on, and changes in the content of the MIB element.
            For example, ISO/CCITT attributes that are converted from
            Internet Object Types acquire matching rules for use in
            filtering operations. ISO/CCITT object classes that are
            created from Internet groups acquire semantics related to
            their inheritance of new attributes from the "top" managed
            object class. The end result is that all the new ISO/CCITT
            object classes, attributes, and notifications created during
            the translation process must be registered. In addition,
            name bindings for inserting object instances into the naming
            hierarchy must be registered.
     
     
            2.1.1 Automated Registration Procedures
     
            Registration procedures are critical to the goals of
            automating the translation of Internet MIBs to ISO/CCITT
            GDMO format, and the efficient implementation of ISO/CCITT-
            Internet proxies. Registration involves assignment of an
            ASN.1 Object Identifier (OID) to the entity. Management
            entities defined according to the principles of the Internet
            SMI may be registered under the IAB's "internet" arc, or
     
            LaBarre             Expires August, 1994              Page 8
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            registered under an arc in another organization's
            proprietary registration subtree.
     
            Since OIDs can be guaranteed to be unique across
            organizations only within the context of the uppermost
            registration hierarchy, this document uses the entire OID to
            prevent ambiguity. The effect of the registration procedure
            specified in this document is to graft the entire OID to
            another part of the registration tree, without changing the
            OID structure.
     
            This document allocates an arc in the registration hierarchy
            for use in automated registration of management elements
            defined according to IIMC procedures defined in this
            document. The arc is named "iimcAutoTrans", and is
            registered in section 4.2.
     
            The following paragraphs describe IIMC registration
            procedures to facilitate automated translation and assure
            uniqueness of registered ASN.1 object identifiers for
            ISO/CCITT object classes and attributes derived from
            internet entities; and a registration procedure for their
            name bindings, document identifiers, and ASN.1 modules.
     
            2.1.1.1 Translated Object Classes and Attributes
                   Registration
     
            Follow the procedure below for OIDs associated with Internet
            groups, conceptual tables, conceptual table entries, and
            objects.
     
            a) Determine the sequence of sub-identifiers of the OID
            assigned to the internet management entity, beginning at the
            root of the registration tree, and identify that sequence as
            <internetEntityId>,
     
             Note:    Remember, the first part of the ASN.1 BER encoded
                   OID must be translated into two sub-identifiers.
     
            b) Determine the translated OID {<iimcTransOID>} as:
     
                  {<iimcTransOID>} = {<iimcAutoObjAndAttr>
                  <internetEntityId>}
     
            where <iimcAutoObjAndAttr> is the OID dedicated for
            ISO/CCITT-Internet automated registration of translated
            object classes and attributes.
     
            This procedure preserves the unique identification of the
            entities within the Internet subtree, and entities
            identified by OIDs that are registered by other
            organizations.
     
     
     
            LaBarre             Expires August, 1994              Page 9
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            2.1.1.2 Translated NAME BINDINGs Registration
     
            As described in section 2.2.2 , the ISO/CCITT SMI requires
            that managed object instances be bound into a naming
            hierarchy, or tree, for purposes of naming. ISO/CCITT NAME
            BINDING templates are used to register the manner in which
            such instances may be bound. These name bindings shall be
            registered.
     
            The Internet SMI does not include the concept of a naming
            tree and name binding. Thus, there exists no registered
            internet entity from which an OID for the ISO/CCITT NAME
            BINDING template can be derived. One solution is to use the
            object class OID to register name bindings under a special
            registration arc {iimcAutoNameBinding}. The following
            procedure shall be followed for registration of a single
            name binding for an object class to be inserted into the
            naming hierarchy, i.e., the subordinate object class.
     
            *  Assign each new name binding an OID, using the following
               rules. Start with the OID for the subordinate object
               class, derived using the procedures in section 2.1.1.1.
               Within the class OID, extract the <internetEntityId>(c)
               portion of the OID. Prepend {iimcAutoNameBinding} to the
               <internetEntityId>(c) so that the OID for the name
               binding is of the form:
     
                  {iimcAutoNameBinding <internetEntityId>(c)}
     
             WARNING: Object Identifiers for name bindings produced
                   during the translation process are only provisionally
                   assigned. The object identifiers are not registered
                   until approved by the registration authority. In
                   cases of conflict with existing registered name
                   bindings that have different creation or deletion
                   semantics, or behaviour characteristics, the
                   registration authority will manually assign object
                   identifiers to the name binding.
     
             Note: In general multiple name bindings may be defined for
                   an ISO/CCITT object class. However the automated
                   registration procedures defined in this document only
                   provide for a single name binding. This facilitates
                   the proxy translation process, especially for
                   received traps/notifications and informRequests.
     
            2.1.1.3 Translated ASN.1 Modules and Documents Registration
     
            Translated MIBs may contain definitions that can be
            referenced by other documents, e.g., attribute types defined
            in this document. An identifier and registered OID shall be
            given to each such document so that management elements
            defined therein may be referenced. Documents that contain
            translated MIBs derived from RFCs, unless manually assigned,
     
            LaBarre             Expires August, 1994             Page 10
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            shall be automatically assigned short document identifiers,
            i.e., a document alias, of the form:
     
                  "iimcRFC" || <rfc number> [|| <rfc number>]*,
     
            where <rfc number> is the internet number assigned to the
            RFC. If multiple RFCs are included in the translation, then
            the RFC numbers shall be concatenated in ascending sequence.
            Document aliases may be manually assigned by the
            registration authority.
     
             Note:    Multiple RFCs are included in the same translated
                   MIB in exceptional cases, not as a general rule.
     
            Documents derived from MIBs defined in Internet RFCs are
            registered under the {iimcAutoDocument} arc by concatenating
            the RFC number onto that arc. If multiple RFCs are included
            in the translation, then the RFC numbers shall be
            concatenated to iimcAutoDocument in ascending sequence.
            Explicit registration of other IIMC documents shall be under
            the iimcDocument arc.
     
            Documents that define translated MIBs contain syntax in
            ASN.1 modules that can be referenced by other documents. An
            identifier and registered OID shall be given to each such
            ASN.1 module so that syntax defined therein may be
            referenced. ASN.1 modules in documents that contain
            translated MIBs derived from RFCs, unless manually assigned,
            shall be automatically assigned short module identifiers,
            i.e., a module alias, of the form:
     
                  "IIMCRFC" || <rfc number> [|| <rfc number>]* ||
                  "ASN1",
     
            where <rfc number> is the internet number assigned to the
            RFC. If multiple RFCs are included in the translation, then
            the RFC numbers shall be concatenated in ascending sequence.
            Module aliases may be manually assigned by the registration
            authority.
     
            Modules derived for MIBs defined in Internet RFCs are
            registered under the {iimcAutoModule} arc by concatenating
            the RFC number onto that arc. If multiple RFCs are included
            in the translation, then the RFC numbers shall be
            concatenated to iimcAutoModule in ascending sequence.
            Explicit registration of other IIMC ASN.1 modules shall be
            under the iimcModule arc.
     
            Translated MIBs defined according to the procedures
            described in this document shall be documented in the
            following format.
     
            *  The OID of the document shall be specified first as
     
     
            LaBarre             Expires August, 1994             Page 11
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                  <document alias> OBJECT IDENTIFIER ::= {<document
                  OID>}
     
               where <document alias> is the short document identifier
               derived as described previously, e.g., iimcRFC12131354,
               and <document OID> is the OID assigned to the document
               using the procedures described in this clause, e.g.,
               {iimcAutoDocument 1213 1354}.
     
            *  The order in which definitions shall appear is:
                    * managed object classes,
                    * attribute types,
                    * attributes, and
                    * ASN.1 Modules.
     
               All text that is not part of the GDMO template, or ASN.1
               definitions shall be preceded by "--" to indicate that
               they are comments. This includes clause headers.
     
            2.1.1.4 Naming Attribute Registration
     
            As described in 2.2.1, the conversion of Internet MIBs to
            ISO/CCITT MIBs requires that naming attributes be defined
            and registered for each ISO/CCITT object class derived from
            Internet management entities. Naming attributes shall be
            registered as
     
                  {iimcAutoName <internetEntityId>(c)},
     
            where <internetEntityId>(c) is the OID assigned to the
            Internet entity from which the associated ISO/CCITT object
            class is derived.
     
     
            2.1.2 IIMC Explicit Registration Procedures
     
            Automated registration procedures alone are not sufficient
            to support the translation process. ISO/CCITT management
            entities other than translated objects, attributes, modules,
            and documents need to be explicitly registered. These
            entities include:
     
            *  common ASN.1 modules that may be referenced for inclusion
               in other ASN.1 modules of other documents,
     
            *  IIMC documents to enable MIB elements and attribute types
               defined in these documents to be referenced within other
               documents, and
     
            *  IIMC defined management elements, such as the generic
               notification defined in this document, the IIMC Proxy MIB
               defined in [23], the IIMC ACL MIB defined in [24], and
               the omibtransSpt MIB defined in [25].
     
     
            LaBarre             Expires August, 1994             Page 12
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            This document allocates an arc in the registration hierarchy
            for explicitly registering IIMC management entities. The arc
            is named "iimcManual". This document assigns sub-arcs under
            the "iimcManual" arc in the ASN.1 module in section 4.2.
     
            2.1.2.1 Explicit ASN.1 Modules and Documents Registration
     
            Explicit registration of IIMC documents shall be under the
            iimcDocument arc, as specified in section 4.2. For example,
            this document iimcIIMCIMIBTRANS is registered as
            {iimcDocument 1}.
     
            Explicit registration of IIMC ASN.1 modules shall be under
            the iimcModule arc, as specified in section 4.2. For
            example, the IimcAssignedOIDs module specified in section
            4.2 of this document is registered as {iimcModule 1}.
     
            2.1.2.2 Explicit Trap/Notification Registration
     
            Internet traps/notifications and informRequests are not
            considered by the Internet SMI to be associated with any one
            object or group. The ISO/CCITT SMI, however, requires that a
            notification be emitted by a specific object instance.
            Therefore, determining which ISO/CCITT managed object class
            should emit specific internet traps/notifications is
            problematic.
     
            This document defines a generic IIMC notification,
            internetAlarm (see 3.2.4 and 4.1.4) that is used to carry
            all Internet traps/notifications and informRequests. This
            notification is to be emitted according to the conditions
            described in section 3.2.4 either by the
            {iimcRFC12131354}:internetSystem managed object defined in
            [22] and derived from the internet system group defined in
            [14], or by the {iimcIIMCProxy}:cmipsnmpProxyAgent managed
            object defined in [23]. However, each Internet defined
            trap/notification and informRequest must be registered such
            that they may be differentiated within the IIMC generic
            notification.
     
            Internet traps/notifications are registered using the OID
            corresponding to the value of the Internet snmpTrapOID
            object defined in [20].
     
            For SNMPv1 trap PDUs, the snmpTrapOID is derived as stated
            in the SNMPv1/SNMPv2 Coexistence document [21] 3.1.2(2).
            That definition is repeated below:
     
                  "... if the value of the generic-trap field is
                  'enterpriseSpecific' then the value used is the
                  concatenation of the enterprise field from the trap
                  PDU with two additional sub-identifiers, '0', and the
                  value of the specific-trap field."
     
     
            LaBarre             Expires August, 1994             Page 13
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            For notifications, informRequests, defined according to the
            SNMPv2 SMI, the registered OID is the value of the
            snmpTrapOID.
     
            The registered OID for the Internet trap/notification is
            then used as the value for the probableCause field of the
            IIMC generic notification, internetAlarm, as defined in
            section 3.2.4 and 4.1.4.
     
     
     
            2.2 NAMING PROCEDURES
     
            ISO/CCITT objects are identified by specifying read-only
            attributes within the object class as naming attributes. The
            naming attribute is used to form the relative distinguished
            name of the object instance. The sequence of relative
            distinguished names that trace the path in the naming
            hierarchy from the root to the object forms a distinguished
            name that uniquely identifies the object instance.
     
     
            2.2.1 Naming Attributes
     
            The conversion of Internet MIBs into ISO/CCITT GDMO MIBs
            requires that naming attributes be defined and registered
            for each ISO/CCITT object class derived from Internet
            management entities.
     
            This paper specifies conventions for naming attributes:
            their labeling, registration, and value definition, to
            facilitate automated generation of naming attributes for
            object classes derived from Internet MIBs.
     
            The convention for assigning labels to naming attributes
            shall be to append "Id" to the label of the object class
            with which they are associated.
     
            The convention for assigning registration OIDs to naming
            attributes is described in 2.1.1.4.
     
            The convention for assigning syntaxes to naming attributes
            for instance identification shall be as follows.
     
            The naming attribute value syntax shall be either an ASN.1
            NULL syntax or an ASN.1 SEQUENCE identifying the Internet
            INDEX objects used to name the object class and their
            syntax.
     
            Managed objects for which only a single instance resides in
            the managed system, e.g., {iimcRFC12131354}:tcp, shall use
            the ASN.1 NULL for their syntax. Managed object classes that
            may have multiple instances, e.g., table entries, shall use
            as their syntax an ASN.1 SEQUENCE that contains syntaxes of
     
            LaBarre             Expires August, 1994             Page 14
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            the internet objects identified in the INDEX (or AUGMENTS)
            clause of the Internet Macro from which the object class is
            derived, as defined in [11] or [17]. The values of the
            indexing attributes shall be transferred using the ASN.1
            syntax specified for the Internet objects.
     
            Syntax specifications for single instance naming attributes
            shall be of the form:
     
                  <naming attribute label> || "IdValue" ::= NULL.
     
            Syntax specifications for multiple instance naming
            attributes shall be of the form:
     
                  <naming attribute label> || "IdValue" ::=   SEQUENCE
                      {
                         <index label>  <tag>  <index syntax>
                      [, <index label>    <tag>   <index syntax>]*i }
     
            where the following definitions apply.
     
            <naming attribute label> -- The label of the naming
            attribute which is derived by appending "Id" to the label of
            the object class for which the naming attribute is being
            defined.
     
            <index label> -- The label of an Internet object which is
            listed in the INDEX clause of the Internet entity from which
            the ISO/CCITT object class is derived.
     
            <index syntax> -- The syntax associated with the Internet
            object having the associated <index label>.
     
            The values of INDEX variables used in the naming attribute
            structure shall NOT follow the IMPLIED semantics defined in
            SNMPv2.
     
            <tag>-- For multiple instance object classes, the index
            variables shall be listed, and tagged, within the SEQUENCE
            in the order of their appearance in the INDEX clause of the
            associated OBJECT-TYPE macro from which the ISO/CCITT object
            class is derived. Each ASN.1 tag has the syntax "[i]", where
            i = 1 to the number of index variables.
     
     
            2.2.2 ISO/CCITT-Internet Naming Tree
     
            The ISO/CCITT SMI requires that managed object instances
            (conventionally just called managed objects) be bound into a
            naming hierarchy, or tree, for purposes of naming. This
            hierarchy is often called the containment hierarchy. The
            binding must specify for each managed object class: the
            object class which is superior to it in the containment
            hierarchy; and a naming attribute in the object class that
     
            LaBarre             Expires August, 1994             Page 15
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            is used to distinguish instances of the object class at a
            given level in the hierarchy. The name binding is specified
            after the object class has been defined.
     
     
            2.2.3 Distinguished Names
     
            The distinguished name (DN) of a managed object consists of
            a sequence of relative distinguished names (RDN), one for
            each managed object on the naming path from the root to the
            managed object. Each relative distinguished name contains
            exactly one attribute, the "naming" attribute for the
            corresponding class, as specified by a NAME BINDING
            template. This DN is used as the CMIP ManagedObjectInstance
            or BaseObjectInstance parameter for identifying managed
            objects.
     
            For example, a distinguished name designating a particular
            routing table entry (of class ipRouteEntry) might be:
     
            {
            {"Rec. X.721 | ISO/IEC 10165-2 : 1992":systemTitle     =
                 "troi.mitre.org"}
            {{iimcRFC12131354}:ipId                 =    NULL      }
            {{iimcRFC12131354}:ipRouteEntryId            =    SEQUENCE
                 {
                                               ipRouteDest {129.83.2.17}
                                               }
            }
     
            with appropriate ASN.1 tags, etc., included.
     
             Note: The beginning of the above example distinguished name
                   is implementation dependent. For example, the naming
                   attribute for the system object could have been
                   chosen to be the systemId attribute instead of the
                   systemTitle attribute, and the system object could
                   have been bound to object classes other than root.
     
     
     
            2.3 OID TRANSLATION
     
            The procedures required to translate between Internet
            registered OIDs and names, and ISO/CCITT registered
            attribute and class OIDs are described in this section.
     
     
            2.3.1 OID/Name Translation ISO/CCITT to Internet
     
            The general procedure for deriving ISO/CCITT registered OIDs
            from Internet OIDs was explained in section 2.1, and the
            structure of the naming attribute value was explained in
            section 2.2. This paragraph explains how the information
     
            LaBarre             Expires August, 1994             Page 16
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            used in an ISO/CCITT case OID, attribute OID, and the naming
            attribute value may be used to create the identifier for
            naming Internet objects.
     
            The following definitions apply: ((c) and (a) refer to class
            and attribute, respectively)
     
            From 2.1,
     
                 {classOID}     ::= {iimcAutoObjAndAttr
            <internetEntityId>(c)}
     
                 and
     
                 {attributeOID}      ::= {iimcAutoObjAndAttr
            <internetEntityId>(a)}
     
            For example, examine the {iimcRFC12131354}:ipRouteEntry
            object class OID:
     
                 {iimcRFC12131354}:ipRouteEntry ::= {iimcAutoObjAndAttr
            1 3 6 1 2 1 4 21 1}
                 where <internetEntityId>(c) ::= 1 3 6 1 2 1 4 21 1,
     
            and an attribute that belongs ipRouteEntry,
            {iimcRFC12131354}:ipRouteNextHop:
     
                 {iimcRFC12131354}:ipRouteNextHop ::=
            {iimcAutoObjAndAttr 1 3 6 1 2 1 4 21 1 7}
                 where <internetEntityId>(a) ::= 1 3 6 1 2 1 4 21 1 7.
     
            Note that the attribute <internetEntityId>(a) for
            ipRouteNextHop is equal to <internetEntityId>(c) for its
            associated object class, ipRouteEntry, with the sub-
            identifier (7) appended to it. Most of the time the
            relationship:
     
                  <internetEntityId>(a) ::= <internetEntityId>(c) <sub-
                  identifier>
     
            is true for translated MIB attributes. This property is
            useful for determining the object class and object instance
            with which an attribute may be associated during run-time
            translation of Internet object instances contained in SNMP
            response PDUs and traps/notifications.
     
             Note: When attributes that were not a part of the original
                   Internet group, or table entry, are included in a
                   translated object class, then this relationship is
                   not valid. For example, derived attributes assigned
                   to an object class because their inclusion was
                   indicated by an SNMPv2 AUGMENTS clause, as discussed
                   in section 3.1.
     
     
            LaBarre             Expires August, 1994             Page 17
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            From 2.2, the ISO/CCITT naming attribute value contains
            either an ASN.1 NULL value, or a list of index variables in
            an ASN.1 SEQUENCE with their values represented in their
            appropriate syntax (where the "( )" indicates "contents
            of"):
     
                 (naming attribute)  ::=  <internet instanceId>
     
            where the <internet instanceId> is an ASN.1 NULL, or a
            SEQUENCE identifying the INDEX attributes used to name the
            object class, and their syntax. Managed objects for which
            only a single instance resides in the managed system, e.g.,
            {iimcRFC12131354}:tcp and {iimcRFC12131354}:ip, shall use
            the ASN.1 NULL for their value. Managed object classes that
            may have multiple instances, e.g., table entries, shall use
            as their value an ASN.1 SEQUENCE that contains values of the
            attributes derived from internet objects identified in the
            INDEX (or AUGMENTS) clause of the Internet Macro from which
            the object class is derived, as defined in [11] or [17].
     
            For example, the ISO/CCITT naming attribute value for the
            instance of {iimcRFC12131354}:ipRouteEntry specific to IP
            address "129.83.2.17" contains the ipDestination index
            variable as an IP address represented in an ASN.1 OCTET
            STRING of size 4 as specified in [RFC1242].
     
            The Internet uses the following convention to uniquely
            identify an Internet object instance:
     
                  {internet object name}::= {<internetEntityId>(a)
                  <internet instanceId>}
     
            For example, the internet object name for ipRouteNextHop
            corresponding to IP address 129 83 2 17 is {1 3 6 1 2 1 4 21
            1 7 129 83 2 17}, where <internetEntityId>(a) ::= 1 3 6 1 2
            1 4 21 1 7, <internetInstanceId> ::=129 83 2 17.
     
            Therefore, given the contents of the naming attribute for
            the ISO/CCITT object instance being accessed, the <internet
            instanceId> is extracted. Given the attributeOID for the
            attribute being operated upon, the <internetEntityId>(a) is
            extracted. The {internet object name} is then formed from
            the results, taking into account appropriate conversions
            from their ASN.1 representation.
     
            For example, assume that a CMIS request is issued specifying
            a distinguished name for an {iimcRFC12131354}:ipRouteEntry
            managed object as illustrated in section 2.2.3; and an
            attribute for ipRouteEntry, say
            {iimcRFC12131354}:ipRouteNextHop. The ipRouteNextHop
            attribute has been assigned the identifier
            {iimcAutoObjAndAttr 1 3 6 1 2 1 4 21 1 7} in the MIB defined
            in [22]. Therefore, the ipRouteNextHop attribute identifier
            would first have to be translated into the corresponding
     
            LaBarre             Expires August, 1994             Page 18
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            Internet identifier {1 3 6 1 2 1 4 21 1 7} by stripping off
            the iimcAutoObjAndAttr portion of the OID. Then, from the
            RDN value for the ipRouteEntry extract the value for the
            <internet instanceId>, i.e., the value for the ipRouteDest
            index "129 83 2 17". Finally the Internet identification for
            this piece of management information would be constructed
            according to [14] as {ipRouteNextHop 129 83 2 17}, or
            equivalently, {1 3 6 1 2 1 4 21 1 7 129 83 2 17}. The agent
            with which this information resides is identified (see
            2.2.3), by the RDN for the system managed object naming
            attribute, e.g., the "systemTitle", as "troi.mitre.org."
     
     
            2.3.2 OID/Name Translation Internet to ISO/CCITT
     
            Internet to ISO/CCITT OID/name translation is only necessary
            when used during run-time proxy translation. At run-time
            internet identifiers are provided as internet object names
            in SNMP responses and traps/notifications. The internet
            object names are of the form described in section 2.3.1.
            Although actual translation is required only during run-time
            in proxy implementations, the translation properties, and
            information that may be obtained, must be understood in
            order to properly define the structure of the IIMC generic
            notification, internetAlarm, defined in section 3.2.4.
     
            Given the definitions shown in section 2.3.1, and knowledge
            of the IIMC naming hierarchy (name bindings), the ISO/CCITT
            {classOID},{attributeOID}, and distinguished name can be
            derived from Internet names and the Internet agent address.
     
            *  The iimcAutoObjAndAttr OID is known.
     
            *  Using knowledge of the internet name structure as
               described in section 2.3.1, and knowledge of valid
               <internetEntityId>(a) values known to the proxy, the
               <internetEntityId>(a) and <internet instanceId> may be
               extracted from the internet name.
     
             Note: The extraction process is not possible if the valid
                   <internetEntityId>(a) value is not known to the
                   proxy. The translation process cannot be performed.
     
            *  The ISO/CCITT attribute OID is formed as:
     
                  {iimcAutoObjAndAttr <internetEntityId>(a)}
     
            *  The ISO/CCITT class OID may be determined in one of two
               ways:
     
                  i) assume that the <internetEntityId>(a) contains the
                  object class OID, <internetEntityId>(c), with which
                  the attribute may be associated, as discussed in
                  section 2.3.1. Then stripping off the final component
     
            LaBarre             Expires August, 1994             Page 19
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                  of the OID will yield the <internetEntityId>(c). The
                  object class OID is then formed as {iimcAutoObjAndAttr
                  <internetEntityId>(c)}. However, see the note in
                  section 2.3.1.
     
                 ii) use a safer approach, and determine the class OID
                 by looking up the ISO/CCITT object class OID to which
                 the attribute identified as {iimcAutoObjAndAttr
                 <internetEntityId>(a)} belongs.
     
            *  The naming attribute OID may be derived by extracting the
               <internetEntityId(c)> from the class OID derived
               previously, and prepending it with the OID for
               {iimcAutoName} as described in 2.1.1.4.
     
            *  The managed object instance value, the object's DN, may
               be determined as follows:
     
                  a) the value of the naming attribute associated with
                  the object class may be formed as:
     
                      <internet instanceId>.
     
                  b) the naming attribute value, and the naming
                  attribute OID defined in section 2.2.1, are used to
                  form the final RDN for the object's DN. The sequence
                  of other RDNs for the DN are determined from knowledge
                  of the naming hierarchy defined for proxy [23], i.e.,
                  the IIMC proxy name bindings, and the Internet agent's
                  address.
     
             Note: If the Internet agent's address cannot be determined,
                   then it may not be possible to associate a
                   notification with a specific agent. This may be a
                   problem if multiple Internet agents are associated
                   with the same network address.
     
     
     
            2.4 INHERITANCE FOR OBJECT CLASSES
     
            The "Rec. X.721 | ISO/IEC 10165-2 : 1992":top class defined
            by [8] is the ultimate superior in the ISO/CCITT inheritance
            hierarchy. The class "top" contains attributes which are
            inherited by all managed object classes that are defined
            using the ISO/CCITT SMI and GDMO templates.
     
            Not all attributes of "top" need to be instantiated in any
            single managed object. All objects shall instantiate the
            mandatory "objectClass", and "nameBindings" attributes. If
            conditional packages may apply, an object shall instantiate
            the "packages" attribute.
     
     
     
            LaBarre             Expires August, 1994             Page 20
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            2.5 REFERENCE LABELS FOR DERIVED ENTITIES
     
            The labels used to reference Internet entities (groups,
            objects, traps) shall be used to reference the corresponding
            templates for the derived ISO/CCITT entity (object class,
            attribute, notification).
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994             Page 21
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
                 3. INTERNET TO ISO/CCITT MIB TRANSLATION PROCEDURES
     
            The procedures for translating Internet SMI MIBs into
            ISO/CCITT SMI MIBs consist of pre-translation procedures,
            GDMO template translation procedures, and post-translation
            procedures. Many of the procedures are subject to
            automation; some are not. Comments are provided concerning
            possible aids to automation; however, it is not the intent
            of this document to provide fully automated translation
            algorithms.
     
     
     
            3.1 PRE-TRANSLATION PROCEDURES
     
            Pre-translation procedures are outlined below. The rationale
            for steps (a)-(d) is that the ISO/CCITT object classes and
            associated attributes must be identified. The rationale for
            steps (e)-(f) is that all ASN.1 syntax references in
            templates must be an ASN.1 External type reference or
            External value reference, i.e., must reference a label that
            appears on the left side of an ASN.1 construct within some
            ASN.1 module that appears in the document that defines the
            derived MIB. Internet MIBs often reference basic ASN.1
            constructs, such as INTEGER and OCTET STRING, which must be
            converted into an External type reference. Default values
            must reference an External value reference.
     
            (a) Identify Internet groups and OBJECT-TYPEs associated
              with each group. For SNMPv2 defined MIBs, the OBJECT-GROUP
              macro includes this information. For SNMPv1 defined MIBs,
              the group may be identified manually and then the members
              of the group identified by the fact that their OIDs
              contain the group object identifier. For SNMPv1 defined
              MIBs, procedure (c) must be followed.
     
            (b) Identify conceptual table OBJECT-TYPEs, conceptual table
              entry (row) OBJECT-TYPEs associated with each table, and
              columnar OBJECT-TYPEs associated with each conceptual
              table entry.
     
              For SNMPv2 defined MIBs, the MAX-ACCESS clause of the
              conceptual table and entry OBJECT-TYPES macro will have a
              value of 'not-accessible', and the convention often used
              is to include the word "Table" or "Entry" in the macro
              label. Once a conceptual table has been identified, the
              corresponding conceptual entry OBJECT-TYPE macro can be
              identified via its registered object identifier through
              the convention of appending a 1 to the table object
              identifier. Alternatively, the conceptual table's SYNTAX
              clause may be examined to determine the label of the
     
            LaBarre             Expires August, 1994             Page 22
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
              corresponding conceptual entry Macro. SNMPv1 defined MIBs
              are not so consistent in their use of "not-accessible";
              however, the other conventions apply.
     
              For SNMPv2 defined MIBs, tables may be defined with table
              entries that augment (SNMPv2 AUGMENT clause) entries for
              an existing table. The table entry object class for the
              augmented table will be bound to the table entry object
              class that corresponds to the reference in the AUGMENTS
              clause.
     
            (c) For each group, the OBJECT-TYPEs not identified in
              procedure (b), and not having an ACCESS or MAX-ACCESS
              clause value of "not-accessible", are identified for
              translation into attributes of an ISO/CCITT object class
              associated with the group. The OBJECT-TYPEs that have an
              ACCESS or MAX-ACCESS clause of 'not-accessible', i.e.
              conceptual table and conceptual table entry objects, are
              not translated.
             Note: Some groups may not have any OBJECT-TYPEs to
                   translate into attributes.
     
            (d) For each conceptual table entry OBJECT-TYPE, the set
              (set1) of columnar OBJECT-TYPEs associated with the table
              entry are identified for translation into ISO/CCITT
              attributes of an ISO/CCITT object class associated with
              the entry. Another set (set2) of OBJECT-TYPES identified
              in the INDEX clause of the conceptual table entry OBJECT-
              TYPE are also identified for inclusion in the class. If
              the AUGMENTS clause is present, then the INDEX clause of
              the conceptual table entry OBJECT-TYPE pointed to by the
              AUGMENTS clause identifies the elements of (set2). The
              union of these two sets constitutes the set of ISO/CCITT
              attributes associated with the table entry object class.
              All OBJECT-TYPEs are translated, excluding those that have
              an ACCESS or MAX-ACCESS clause of 'not-accessible'.
     
             Note: The set of columnar OBJECT-TYPES associated with a
                   table entry can be identified by the SYNTAX clause
                   for the OBJECT-TYPE for the conceptual table entry.
                   The SYNTAX clause is of the form:
                           SEQUENCE OF <type1,..., typeN>
                   where <typeN> includes the label of an OBJECT-TYPE
                   included in the conceptual table entry.
     
            (e)  Create an ASN.1 module for use in the GDMO template
              translations. Create an IMPORTS clause for the module and
              include in it the syntax to be imported from other
              modules. This may be done by including the parameters for
              the IMPORTS clause encountered in the Internet module. (An
              alternative is to import the syntax for attribute types
              defined in this document from the IimcCommonDef module.
              However, not all of the syntax may be needed, and some
     
     
            LaBarre             Expires August, 1994             Page 23
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
              necessary syntax may be omitted for attribute types
              defined in other MIBs.)
     
              When any Internet TEXTUAL-CONVENTIONS macros that may be
              present in the Internet module are translated according to
              the procedures of 3.2.6, the resulting ASN.1 syntax shall
              be included in the new ASN.1 module. TEXTUAL-CONVENTIONS
              macros shall be translated first so that these ASN.1
              constructs may be used during the translation of OBJECT-
              TYPE macros.
     
              For each OBJECT-TYPE that is to be translated into an
              ISO/CCITT attribute, check the value of the SYNTAX clause,
              and if it is not a syntax included in the IMPORTS clause
              of the new ASN.1 module, or defined using an SNMPv2
              TEXTUAL-CONVENTION macro, then do one of the following:
     
                  i) If the value is not an External type reference:
                  create an External type reference for the value in the
                  SYNTAX clause and put it into the ASN.1 module. The
                  label for the External type reference shall be the
                  attribute label with the first letter capitalized.
     
                  ii) If the value is an External type reference put the
                  External type reference syntax into the ASN.1 module.
     
            (f)  If a DEFVAL clause is present, create an External value
              reference which has the type indicated by the OBJECT-TYPE
              SYNTAX clause and is assigned the value of the DEFVAL
              clause. The label for the External value reference shall
              be the attribute label preceded by "c-" (lower case letter
              "c"). Place the External value reference into the ASN.1
              module created in e). For example, the following would be
              a valid value references (assuming StorageType was
              declared in, or imported to, the same ASN.1 module):
     
                  c-contextStorageType    StorageType    ::= nonVolatile
                  c-xyz              INTEGER   ::= 100.
     
            (g) If the ASN.1 module for the Internet MIB definition
              contains ASN.1 value assignments, then the syntax for
              those value assignments pertinent to the translation shall
              either be placed in the ASN.1 module created in (e) or
              imported into the module using an External value
              reference.
     
             Note: It is recommended that a syntax that is used more
                   than once in the MIB to be translated be defined just
                   once in the new ASN.1 module created in (e) and
                   referenced repeatedly. Examples of such commonly
                   referenced types are INTEGER, OCTET STRING, and
                   OBJECT IDENTIFIER.
     
     
     
            LaBarre             Expires August, 1994             Page 24
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            3.2 GDMO TRANSLATION PROCEDURES
     
            Readers of this document are assumed to have familiarity
            with the GDMO templates and their format. The templates
            structures presented here should be considered definitive
            for MIBs defined according to the translation procedures
            defined in this document.
     
            The GDMO templates in this paragraph contain elements
            indicated by "< x >", where "x" is to be interpreted and the
            result substituted into the template.
     
            The "||" symbol indicates concatenation of elements.
     
            Adjacent elements that are not concatenated shall be
            separated by at least one space.
     
            The "[ ]" symbols surrounding a construct indicate that it
            maybe present or absent in any particular instance of the
            template.
     
            The "[ ]*" symbols surrounding a construct indicate that it
            may be present or absent in any particular instance of the
            template an undefined number of times.
     
            An "|" symbol is used to indicate that a choice must be made
            between alternate constructs.
     
            The "!" symbol is used to delimit text strings in the
            templates. Other delimiters may be used, as specified by the
            GDMO. The delimiter may not be used in the text string
            unless it is "doubled", e.g.,"!!".
     
            Elements that are defined in one template are not repeated
            for other templates unless its interpretation has changed.
     
            The Internet SNMPv2 SMI also includes macros for specifying
            compliance with the MIBs. These macros are similar to
            ISO/CCITT managed object conformance statements (MOCS), and
            are not addressed here.
     
     
            3.2.1 Translation of Groups
     
            Internet groups may be translated to ISO/CCITT managed
            object classes by filling in the following GDMO template:
     
            <group label> MANAGED OBJECT CLASS
                 DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 :1992" :top;
                 CHARACTERIZED BY
                 <group label> || "Pkg" PACKAGE
                      [BEHAVIOUR
                      <group label> || "PkgBehaviour" BEHAVIOUR
                      DEFINED AS !<optional textual definition>!;;]
     
            LaBarre             Expires August, 1994             Page 25
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                 ATTRIBUTES
                      <group label> || "Id" GET
                      ["," <OBJECT-TYPE label n>
                      [DEFAULT VALUE <DEFVAL clause translation>]
                      [PERMITTED VALUES <permitted attribute syntax
                      sub-type>]
                      <OBJECT-TYPE label n ACCESS clause
                      translation>]*;;;
            REGISTERED AS { iimcAutoObjAndAttr <internetEntityId>(c) };
     
            where the following definitions apply.
     
            <group label> -- The label associated with the Internet
            group.
     
            <optional textual definition> -- Any textual description
            that is applicable to the resource modeled by this group,
            and the resource's management behaviour. Text in the SNMPv2
            DESCRIPTION clause of the OBJECT-GROUP macro may be used. To
            facilitate parsing of BEHAVIOUR clauses for classes derived
            from groups, the following scannable structure shall be used
            (the [] indicate optional constructs, keywords must be in
            caps, keywords shall be excluded from the descriptive text,
            keywords shall appear in the order illustrated below):
     
                 [BEGINPARSE
                 [REFERENCE !!
                      <text referencing internet document, group or
                      object from which the ISO/CCITT object class was
                      derived>!!;]
                 [DESCRIPTION !!
                      <applicable textual description, or text of
                      Internet macro DESCRIPTION clause, if present>!!;]
                 ENDPARSE]
     
            The scannable structure shall be the first text in the
            BEHAVIOUR clause.
     
            <OBJECT-TYPE label n> -- The label of an Internet OBJECT-
            TYPE which is included in the group and does not represent a
            conceptual table, a conceptual table entry, or an OBJECT-
            TYPE included in a conceptual table entry. These become
            attributes of the object class.
     
            <permitted attribute syntax sub-type> -- The constraints on
            the attribute values expressed as an ASN.1 subtype that is
            valid for the attribute's syntax. This clause is present
            only when constraints are specified by the source MIB ASN.1
            syntax, but are not specified in the syntax associated with
            the corresponding translated attribute.
     
            <OBJECT-TYPE label n ACCESS clause translation> -- The
            mapping of the ACCESS (or SNMPv2 MAX-ACCESS) clause value as
     
     
            LaBarre             Expires August, 1994             Page 26
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            defined below (multi-valued attributes are not permitted in
            the Internet SMI):
     
            OBJECT-TYPE ACCESS Clause     ISO/CCITT
            Value
            read-only                     GET
            read-write                    GET-REPLACE
            write-only                    REPLACE
            read-create                   not applicable
            not-accessible                not translated
                      Table 1. Mapping the Group ACCESS clause.
     
            <DEFVAL clause translation> -- The value of the DEFVAL
            clause in the form of an External value reference, i.e.,
            <module-name>.<value-name>, where the module-name is the
            name of an ASN.1 module within the document in which this
            object class is defined, and the value-name is the label
            assigned to the ASN.1 value definition contained in the
            DEFVAL clause. Where it is necessary to refer to the label
            of a definition contained in another document, this may be
            achieved by means of a local ASN.1 module which makes use of
            the ASN.1 IMPORTS mechanism to import the appropriate value
            definition.
     
     
            3.2.2 Translation of Table Entry Objects
     
            Internet conceptual table entry objects may be translated to
            ISO/CCITT managed object classes by filling in the following
            GDMO template:
     
            <OBJECT-TYPE label> MANAGED OBJECT CLASS
                 DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992":top;
                 CHARACTERIZED BY <OBJECT-TYPE label> || "Pkg" PACKAGE
                      BEHAVIOUR
                      <OBJECT-TYPE label> || "PkgBehaviour" BEHAVIOUR
                      DEFINED AS
                      !<OBJECT-TYPE DESCRIPTION clause text>!;;
                 ATTRIBUTES
                      <OBJECT-TYPE label> || "Id" GET
                      ["," <OBJECT-TYPE label n>
                      [DEFAULT VALUE <DEFVAL clause translation>]
                      [PERMITTED VALUES <permitted attribute syntax
                      sub-type>]
                      <OBJECT-TYPE label n ACCESS clause
                      translation>]*;;;
            REGISTERED AS {iimcAutoObjAndAttr <internetEntityId>(c) };
     
            where the following definitions apply.
     
            <OBJECT-TYPE label> -- The label of an Internet OBJECT-TYPE
            which represents a conceptual table entry.
     
     
     
            LaBarre             Expires August, 1994             Page 27
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            <OBJECT-TYPE label n> -- The label of an Internet OBJECT-
            TYPE which represents an OBJECT-TYPE included in a
            conceptual table entry. These become attributes of the table
            entry managed object.
     
            <OBJECT-TYPE label n ACCESS clause translation> -- The
            mapping of the ACCESS (or SNMPv2 MAX-ACCESS) clause value as
            defined below (multi-valued attributes are not permitted in
            the Internet SMI):
     
            OBJECT-TYPE ACCESS Clause     ISO/CCITT
            Value
            read-only                     GET
            read-write*                   GET-REPLACE
            write-only                    REPLACE
            read-create*                  GET-REPLACE
            not-accessible                not-translated
               Table 2. Mapping the Table Entry Object ACCESS clause.
     
            * Some attributes that were derived from OBJECT-TYPEs with a
            read-create or read-write access clause will be changed to
            GET during post-translation processing of INDEX type
            attributes. See section 3.3.3.
     
            <OBJECT-TYPE DESCRIPTION clause text> -- To facilitate
            parsing of BEHAVIOUR clauses for classes derived from table
            entries, the following scannable structure shall be used
            (the [] indicate optional constructs, keywords must be in
            caps, keywords shall be excluded from the descriptive text,
            keywords shall appear in the order illustrated below):
     
                 [BEGINPARSE
                 [REFERENCE !!
                      <text referencing internet document, group or
                      object from which the ISO/CCITT object class was
                      derived>!!;]
                 [DESCRIPTION !!
                      <text of Internet macro DESCRIPTION clause, if
                      present>!!;]
                 INDEX
                      [IMPLIED] <Internet ASN.1 module reference> || "."
                           ||<index object label>
                           [,[IMPLIED] <Internet ASN.1 module reference>
                           || "." || <index object label>]*;
                 [AUGMENTS <entry label that the object class
                 augments>;]
                 ENDPARSE]
     
            where the following definitions apply.
     
            IMPLIED -- The key word as encountered in the INDEX clause
            of SNMPv2 MIBs. The SNMPv2 semantics of IMPLIED are to be
            applied to the index variable that it precedes when
            translating from OSI names into Internet names. The values
     
            LaBarre             Expires August, 1994             Page 28
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            of INDEX variables, when used in the naming attribute
            structure, shall NOT follow the IMPLIED semantics defined in
            SNMPv2.
     
            <Internet ASN.1 module reference> -- The label for the ASN.1
            module that contains the Internet MIB definitions,
     
            <index object label> -- The Internet label assigned to the
            object that appears in the Internet macro INDEX clause for a
            table entry.
     
            The scannable structure shall be the first text in the
            BEHAVIOUR clause.
     
     
            3.2.3 Translation of Other OBJECT-TYPES
     
            Other Internet OBJECT-TYPEs are translated into ISO/CCITT
            attributes by filling in the following GDMO template:
     
            <OBJECT-TYPE label> ATTRIBUTE
                 [WITH ATTRIBUTE SYNTAX
                      <module identification>|| "." || <SYNTAX clause
            translation 1>;]
                 | [DERIVED FROM <SYNTAX clause translation 2>;]
                 [MATCHES FOR <SYNTAX clause type matching rules>;]
                 [BEHAVIOUR
                      <OBJECT-TYPE label> || "Behaviour" BEHAVIOUR
                      DEFINED AS
                      !<OBJECT-TYPE DESCRIPTION clause text>!;;]
            REGISTERED AS {iimcAutoObjAndAttr <internetEntityId>(a)};
     
            where the following definition applies.
     
            <module identification> -- The label of the ASN.1 module
            that contains the ASN.1 syntax being referenced. The module
            must appear in the document that defines the translated MIB.
     
            ISO/CCITT have the concept of a generic "attribute type",
            which is a defined type that can be used in the definition
            of specific attributes. Attribute types have a defined
            syntax, generic semantics, and matching rules. For example,
            counter and gauge are attribute types.
     
            The SNMPv2 SMI has a similar concept embodied in the
            TEXTUAL-CONVENTIONS macro, which allows the definition of
            "Internet attribute types" with associated syntax and
            semantics. See section 3.2.6 for translation procedures
            associated with the TEXTUAL CONVENTIONS macro.
     
            Attributes of the defined SNMP types (e.g., Counter,
            IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32,
            Counter64, NsapAddress) shall inherit the semantics
            associated with the type -- not just the syntax. As such,
     
            LaBarre             Expires August, 1994             Page 29
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            they could have been defined as Internet attribute types
            using a TEXTUAL CONVENTIONS macro. See 4.1.4 for the
            conversion of these types into ISO/CCITT attribute types. In
            addition, 4.1.4 contains ISO/CCITT attribute type
            definitions derived from [18].
     
            Attribute templates derived from OBJECT-TYPE macros that
            specify these Internet attribute types in their SYNTAX
            clause shall contain the DERIVED FROM clause. Attribute
            templates derived from other ASN.1 types shall contain the
            WITH SYNTAX clause.
     
            <SYNTAX clause translation 1> -- Translation of the SYNTAX
            clause into a valid type reference name using the ASN.1
            External type reference notation as GDMO requires.
     
            <SYNTAX clause type matching rules> -- The matching rules
            for use in CMIS filtering operations.
     
            These rules also apply to External type references that
            reference the syntax type. These matching rules may be
            applied by automated mechanisms and then examined in the
            post-translation phase.
     
            Syntax Type                   Matching Rules
            INTEGER, ENUMERATED           EQUALITY, ORDERING
            OCTET STRING                  EQUALITY, ORDERING,
                                          SUBSTRINGS
            BIT STRING                    EQUALITY
            OBJECT IDENTIFIER*            EQUALITY, ORDERING
            NULL                          EQUALITY
                         Table 3. Mapping to matching rules.
     
            * ORDERING, when applied to OBJECT IDENTIFIER, refers to the
            lexicographical ordering of the OIDs as used in [12] [19].
     
            See 4.1.2 for the matching rules that are inherited from
            some ISO/CCITT attribute types derived from Internet
            attribute types.
     
            <SYNTAX clause translation 2> -- Attributes of the defined
            SNMP/SNMPv2 types (e.g., Counter, IpAddress, Gauge,
            TimeTicks, Opaque, Counter32, Gauge32, Counter64,
            NsapAddress), and Internet attribute types defined using the
            SNMPv2 TEXTUAL CONVENTIONS macro, shall be treated as
            ISO/CCITT attribute types. Specific attributes are derived
            from these types.
     
            The following table indicates the translations required for
            Internet attribute types as defined either in this document
            or Internet documents. ISO/CCITT attribute types
            corresponding to the following Internet attribute types are
            defined in 4.1.2.
     
     
            LaBarre             Expires August, 1994             Page 30
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            Syntax Type                   Substituted Value
            AutonomousType                {iimcIIMCIMIBTRANS}
                                          :autonomousType
            Counter                       {iimcIIMCIMIBTRANS}
                                          :counter32
            Counter32                     {iimcIIMCIMIBTRANS}
                                          :counter32
            Counter64                     {iimcIIMCIMIBTRANS}
                                          :counter64
            DisplayString                 {iimcIIMCIMIBTRANS}
                                          :displayString
            Gauge                         {iimcIIMCIMIBTRANS} :gauge32
            Gauge32                       {iimcIIMCIMIBTRANS} :gauge32
            InstancePointer               {iimcIIMCIMIBTRANS}
                                          :instancePointer
            IpAddress                     {iimcIIMCIMIBTRANS}
                                          :ipAddress
            MacAddress                    {iimcIIMCIMIBTRANS}
                                          :macAddress
            NetworkAddress                {iimcIIMCIMIBTRANS}
                                          :ipAddress
            NsapAddress                   {iimcIIMCIMIBTRANS}
                                          :nsapAddress
            Opaque                        {iimcIIMCIMIBTRANS} :opaque
            PhysAddress                   {iimcIIMCIMIBTRANS}
                                          :physAddress
            RowStatus                     {iimcIIMCIMIBTRANS}
                                          :rowStatus
            TestAndIncrement              {iimcIIMCIMIBTRANS}
                                          :testAndIncrement
            TimeInterval                  {iimcIIMCIMIBTRANS}
                                          :timeInterval
            TimeStamp                     {iimcIIMCIMIBTRANS}
                                          :timeStamp
            TimeTicks                     {iimcIIMCIMIBTRANS}
                                          :timeTicks
            TruthValue                    {iimcIIMCIMIBTRANS}
                                          :truthValue
            UInteger32                    {iimcIIMCIMIBTRANS}
                                          :uInteger32
                          Table 4. Common attribute types.
     
            <OBJECT-TYPE DESCRIPTION clause text> -- To facilitate
            parsing of BEHAVIOUR clauses for attributes derived from
            Internet objects, the following scannable structure shall be
            used (the [] indicate optional constructs, keywords must be
            in caps, keywords shall be excluded from the descriptive
            text, keywords shall appear in the order illustrated below):
     
                 [BEGINPARSE
                 [REFERENCE !!
                      <text referencing internet document, object from
                      which the ISO/CCITT attribute was derived>!!;]
                 [DESCRIPTION !!
     
            LaBarre             Expires August, 1994             Page 31
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                      <text of Internet macro DESCRIPTION clause, if
                      present>!!;]
                 [UNITS !!
                      <text of Internet macro UNITS clause, if present
                      indicating the units associated with the
                      attribute>!!;]
                 [DEFVAL
                      <value in the Internet macro DEFVAL clause, if
                      present, indicating the default value for the
                      attribute>;]
                 ENDPARSE]
     
            The scannable structure shall be the first text in the
            BEHAVIOUR clause.
     
     
            3.2.4 Translation of Notifications
     
            The Concise MIB Definitions [13] for SNMPv1 does not contain
            a macro for representing traps since, in SNMPv1, traps were
            considered part of the protocol and not part of the MIB. A
            subsequent attempt was made to correct this problem in [15]
            by defining a TRAP-TYPE macro. The SNMPv2 SMI [17] defines a
            NOTIFICATION macro and its mapping onto an SNMPv2 PDU. The
            document on SNMPv1/SNMPv2 Coexistence [21] defines a mapping
            between SNMPv1 trap PDUs and SNMPv2 notifications.
            Therefore, by inference, there exists a mapping of SNMP trap
            PDUs into an SNMPv2 NOTIFICATION macro.
     
            The ISO/CCITT SMI models notifications as being emitted by
            specific managed objects. As a consequence, notifications
            must be assigned to appropriate object classes at the time
            the object class is defined. New notifications cannot be
            added to an object class without changing the class's
            registration.
     
            The Internet SMI has no explicit concept of traps being
            associated with an object. Consequently, determining the
            IIMC derived managed object which is the source of a
            notification is not always possible. Therefore, this
            document defines a generic notification into which all
            Internet traps/notifications may be mapped.
     
            Internet Traps/Notifications may contain information related
            to multiple internet objects. Consequently, the generic
            notification may contain variables not affiliated with the
            same derived ISO/CCITT object class. This document requires
            that variables be placed into the generic notification even
            if they are not attributes of the object class from which
            the notification is emitted.
     
            The generic notification, "internetAlarm", shall be emitted
            by the internetSystem managed object as defined in [22] and
            derived from the internet system group defined in [14]. The
     
            LaBarre             Expires August, 1994             Page 32
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            notification shall be sent in the unconfirmed mode in the
            context that an Internet trap/notification would be sent,
            and in the confirmed mode in the context that an SNMPv2
            InformRequest PDU would be sent.
     
            When generated within a proxy, the events that shall trigger
            the notification to be emitted are the receipt of an
            Internet trap/notification, or an SNMPv2 InformRequest PDU.
     
            In accordance with [7] the decision whether to send a
            notification in the confirmed or unconfirmed mode is a
            matter for the agent to determine based on the policies
            associated with the manager.
     
            The SNMPv2 InformRequest PDU shall cause the notification to
            be sent in the confirmed mode, with the response containing
            no reply information, i.e., the CMIS service shall omit the
            event reply parameter.
     
            All SNMP traps/notifications shall cause the generic
            notification to be sent in the unconfirmed mode.
     
            In the case of proxy, an Internet trap/notification and
            SNMPv2 InformRequest PDU for which the agent address cannot
            be determined by the proxy shall cause the generic
            notification to be emitted by a different object than the
            internetSystem object, as defined in [23].
     
            The internetAlarm notification is defined in section 4.1.4.
     
     
            3.2.5 Log Record for Internet Alarm
     
            If internetAlarm notifications and event reports are to be
            logged, then a corresponding log record object class must be
            defined. The internetAlarmRecord managed object class is
            defined in section 4.1.1.
     
     
            3.2.6 Translation of Internet Attribute Types
     
            ISO/CCITT has the concept of a generic "attribute type",
            which is a defined type that can be used in the definition
            of specific attributes. Attribute types have a defined
            syntax, generic semantics, and matching rules. For example,
            counter and gauge are attribute types.
     
            The SNMPv2 SMI has a similar concept embodied in the
            TEXTUAL-CONVENTION macro, which allows the definition of
            "Internet attribute types" with associated syntax and
            semantics.
     
            Attributes of the defined SNMP types (e.g., Counter,
            IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32,
     
            LaBarre             Expires August, 1994             Page 33
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            Counter64, NsapAddress) should inherit the semantics
            associated with the type -- not just the syntax. As such,
            they could have been defined as Internet attribute types
            using a TEXTUAL-CONVENTION macro.
     
            ISO/CCITT attribute types are defined using the ATTRIBUTE
            template, without the REGISTERED AS clause.
     
            <Internet attribute type label> ATTRIBUTE
                 [[WITH ATTRIBUTE SYNTAX
                      <module identification>|| "." ||<SYNTAX clause
            translation 1>;]
                 | [DERIVED FROM <SYNTAX clause translation 2>;]]
                 [MATCHES FOR <SYNTAX clause type matching rules>;]
                 [BEHAVIOUR
                 <Internet attribute type label>  || "Behaviour"
                      BEHAVIOUR
                      DEFINED AS
                      !<OBJECT-TYPE DESCRIPTION clause text>!;;]
     
            where the following definitions apply.
     
            <Internet attribute type label> -- The label associated with
            the TEXTUAL-CONVENTION macro, or with the generic type that
            could have been defined using that macro.
     
            <OBJECT-TYPE DESCRIPTION clause text> -- To facilitate
            parsing of BEHAVIOUR clauses for attributes derived from
            internet objects, the following scannable structure shall be
            used (the [] indicate optional constructs, keywords must be
            in caps, keywords shall be excluded from the descriptive
            text, keywords shall appear in the order illustrated below):
     
                 [BEGINPARSE
                 [REFERENCE !!
                      <text referencing internet document, object from
                      which the ISO/CCITT attribute was derived>!!;]
                 [DESCRIPTION !!
                      <text of Internet macro DESCRIPTION clause, if
                      present>!!;]
                 [UNITS !!
                      <text of Internet macro UNITS clause, if present
                      indicating the units associated with the
                      attribute.>!!;]
                 [DISPLAY-HINT !!
                      <hints on how to display integer or octet string
                      attributes as defined in [18]. This may be the
                      text of the Internet macro DISPLAY-HINT
                      clause.>!!;
                 ENDPARSE]
     
            The scannable structure shall be the first text in the
            BEHAVIOUR clause.
     
     
            LaBarre             Expires August, 1994             Page 34
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            Attribute templates derived from OBJECT-TYPE macros that
            specify Internet attribute types in their SYNTAX clause
            shall specify the corresponding ISO/CCITT attribute types in
            their DERIVED FROM clause.
     
            In many cases, an SNMP SMI MIB will define a new ASN.1 type
            which is repeatedly referenced by a large number of OBJECT-
            TYPE macros. In this case, it would be useful to define a
            new generic attribute type once and then use DERIVED FROM
            wherever the type is used. Furthermore, if the new ASN.1
            type is actually a refinement of one of the defined SNMP
            types (for example, a refinement of DisplayString), it is
            desirable that the behaviour associated with the defined
            SNMP type gets carried over into the translated MIB. To
            accomplish this, such cases could use the DERIVED FROM
            clause when defining new generic attribute types. For
            example, the ASN.1 syntax:
     
                 DateAndTime ::= DisplayString (SIZE (14))
                 -- comments provide additional semantics
     
            could be represented as a new generic attribute type:
     
            dateAndTime ATTRIBUTE
                 DERIVED FROM {iimcIIMCIMIBTRANS}:displayString;
                 BEHAVIOUR dateAndTimeBehaviour BEHAVIOUR
                 DEFINED AS !<text from comments>!;;
     
            Constraints on the attribute value range, e.g., (SIZE(14))
            from the example, may either be included in the syntax
            definition, if one is specified, or textually in the
            descriptive text. This avoids the problem of always having
            to specify a PERMITTED VALUES clause in the class template
            to constrain the values, or value range, of an attribute
            derived from a generic attribute type. The latter use of
            PERMITTED VALUES is recommended only for special cases where
            additional special constraints are to be applied.
     
     
     
            3.3 POST-TRANSLATION PROCEDURES
     
            Post-translation procedures generally include manual
            checking of the BEHAVIOUR clause text for proper behaviour
            definitions, the addition of information concerning
            variables for creation and deletion in the case of NAME
            BINDING templates, and the creation of name bindings for
            placing the derived ISO/CCITT objects into the containment
            hierarchy. Also, ATTRIBUTE templates must be created for the
            naming attributes assigned to the derived ISO/CCITT object
            classes.
     
     
     
     
            LaBarre             Expires August, 1994             Page 35
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            Post-translation of the property-label is required for
            attributes derived from Internet objects used in conceptual
            table entry creation and deletion.
     
            Post-translation may also be required for the ASN.1 module
            created during the translation process.
     
     
            3.3.1 Post-translation of BEHAVIOUR Cause
     
            The SNMP and SNMPv2 text descriptions often contain
            SNMP/SNMPv2 protocol, or SMI, relevant information that is
            inappropriate for an ISO/CCITT object class or attribute;
            such text shall be removed or properly modified.
     
            For BEHAVIOUR clauses in NAME BINDING templates, the
            behaviour of the object relative to creation and deletion,
            and any constraints that pertain, shall be explained,
            especially if the action causes an effect on the resource,
            e.g., deletion of a transport connection object may cause
            the transport connection to be terminated.
     
            The scannable structures within the BEHAVIOUR shall be
            checked for completeness and missing fields filled in.
     
     
            3.3.2 Creation of NAME BINDING Templates
     
            The ISO/CCITT name bindings for object classes to be bound
            into the naming hierarchy described in section 2.2.2 are
            created by filling in the GDMO template defined below.
     
            <subordinate-superior MOC labels>||"NB" NAME BINDING
                 SUBORDINATE OBJECT CLASS
                      <object class label> AND SUBCLASSES;
                 NAMED BY SUPERIOR OBJECT CLASS
                      <superior object class label> AND SUBCLASSES;
                 WITH ATTRIBUTE
                      <object class label> || "Id";
                 BEHAVIOUR
                 <subordinate-superior MOC labels> || "Behaviour"
                      BEHAVIOUR
                      DEFINED AS !<Behaviour text>!;;
                 [CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-
            OBJECT;]
                 [DELETE DELETES-CONTAINED-OBJECTS;]
            REGISTERED AS { <name binding OID>};
     
            <subordinate-superior MOC labels> -- The combination of the
            subordinate and superior managed object class reference
            labels separated by a hyphen. An example of the resulting
            label is: ip-systemNB.
     
     
     
            LaBarre             Expires August, 1994             Page 36
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            <superior object class label> -- The reference label of the
            superior object class in the naming hierarchy.
     
            Table entry object classes, derived from conceptual table
            entries, have the object class derived from the group in
            which they are contained as their superior. One way to
            determine the group is to use the structure of the OID for
            the table entry object class, i.e., it contains the internet
            specific portion of the OID for the group. However, table
            entry object classes derived from OBJECT-TYPES that contain
            an AUGMENTS clause have the table entry object class derived
            from the OBJECT-TYPE referenced in the AUGMENTS clause as
            their superior.
     
            <Behaviour text> -- If required, the behaviour clause shall
            describe any conditions, beyond the superior versus
            subordinate relationship, concerning the creation or
            deletion of the object relative to the existence of other
            objects, or attribute values in other objects.
     
            To facilitate parsing of BEHAVIOUR clauses for name
            bindings, the following scannable structure shall be used
            (the [] indicate optional constructs, keywords must be in
            caps, keywords shall be excluded from the descriptive text,
            keywords shall appear in the order illustrated below):
     
                 [BEGINPARSE
                 [REFERENCE !!
                      <text referencing internet document, group or
                      object from which the ISO/CCITT object class was
                      derived>!!;]
                 [DESCRIPTION !!
                      <text describing object create/delete
                      behaviour>!!;]
                 [INDEX
                      [IMPLIED] <Internet ASN.1 module reference> || "."
                      ||<index object label>
                      [,[IMPLIED] <Internet ASN.1 module reference> ||
                      "." || <index object label>]*;]
                 [AUGMENTS
                      <entry label that the object class augments>;]
                 [DELETEATT
                      <label of Internet OBJECT-TYPE used for deletion
                      of conceptual table entry object>;
                 [DELETEVALUE
                      SNMPV2ROWSTATUS |
                      <valid ASN.1 value of DELETEATT object indicating
                      deletion>;]
                 ENDPARSE]
     
            where the following definitions apply.
     
            IMPLIED -- The key word as encountered in the INDEX clause
            of SNMPv2 MIBs. The SNMPv2 semantics of IMPLIED are to be
     
            LaBarre             Expires August, 1994             Page 37
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            applied to the index variable that it precedes when
            translating from OSI names into Internet names. The values
            of INDEX variables, when used in the naming attribute
            structure, shall NOT follow the IMPLIED semantics defined in
            SNMPv2.
     
            <Internet ASN.1 module reference> -- The label for the ASN.1
            module that contains the Internet MIB definitions.
     
            <index object label> -- The Internet label assigned to the
            object that appears in the Internet macro INDEX clause for a
            table entry.
     
            The SNMPV2ROWSTATUS keyword indicates that the definition of
            the attribute type rowStatus (see 4.1.2), designed for use
            in SNMP row creation and deletion, is the DELETEATT
            attribute type. The semantics and syntax of rowStatus are
            appropriate for a proxy to use for row creation and
            deletion.
     
            The DELETEATT and DELETEVALUE constructs shall appear in the
            scannable behaviour if the name binding specifies that the
            object class may be created or deleted, i.e., the CREATE and
            DELETE clauses appear in the name binding.
     
            The scannable structure shall be the first text in the
            BEHAVIOUR clause.
     
            For example, the INDEX clause for the {iimcRFC1447}:aclEntry
            in the Party MIB translation is translated as:
     
                 INDEX     SNMPv2-Party-MIB.aclSubject,
                      SNMPv2-Party-MIB.aclTarget,
                      SNMPv2-Party-MIB.aclResources;
     
            The INDEX clause for the {iimcRFC1447}:contextEntry in the
            Party MIB translation is translated as:
     
                 INDEX     IMPLIED SNMPv2-Party-MIB.contextIdentity;
     
            The INDEX clause for the {iimcRFC1447}:viewEntry in the
            Party MIB translation is translated as:
     
                 INDEX     SNMPv2-Party-MIB.viewIndex,
                      IMPLIED SNMPv2-Party-MIB.viewSubtree;
     
            The Internet SMI only allows the possibility of conceptual
            table entries being created and deleted. Many table entries
            are automatically created and deleted as a result of normal
            resource operation, and are not appropriate for creation and
            deletion by management means. However, dynamic creation and
            deletion of such objects by management may still be desired,
            e.g., for interface cards that may be dynamically added or
            removed. Another example is to allow the deletion of
     
            LaBarre             Expires August, 1994             Page 38
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            transport connections by management, thereby causing the
            transport connection to be terminated.
     
            For SNMPv2 defined MIBs, if the table entry contains an
            OBJECT-TYPE that has a SYNTAX clause value of "RowStatus"
            and a MAX-ACCESS clause value of "read-create", then the
            name binding for the table entry shall contain the CREATE
            and DELETE clauses, and appropriate scannable clauses in the
            BEHAVIOUR clause, as specified in the template defined in
            this clause.
     
            For SNMPv1 defined MIBs, the use of an object for the
            purposes of creation and deletion is inconsistent. Usually,
            the text definition for the table entry may need to be
            consulted to determine if creation and deletion are allowed,
            and to determine the columnar object with an ACCESS clause
            of "read-write" and an associated value which indicates
            deletion. If a columnar object is defined in the entry that
            is used for creation and deletion, then the name binding for
            the table entry shall contain the CREATE and DELETE clauses,
            and appropriate scannable clauses in the BEHAVIOUR clause,
            as specified in the template defined in this clause.
     
            If a columnar object is not defined in the entry for use in
            creation and deletion, then the name binding for the table
            entry shall not contain the CREATE and DELETE clauses, and
            associated scannable clauses in the BEHAVIOUR clause, as
            specified in the template defined in this clause.
     
            Name bindings definitions that do not adhere to the criteria
            stated above for inclusion or exclusion of CREATE and DELETE
            clauses for object classes derived from SNMPv1 and SNMPv2
            entities, or for which behaviour clauses contain different
            semantics than are defined for the Internet equivalent
            entity, shall be noted in the System Conformance Statement
            (SCS) in Annex A.
     
            <name binding OID> -- As defined in section 2.1.1.2.
     
            The conventions for name binding registration shall be as
            defined below.
     
            Object classes derived from Internet groups shall be bound
            to the ISO/CCITT system object class defined in [8]. Object
            classes derived from Internet conceptual table entries shall
            be bound to the object classes derived from the group with
            which they are associated. Object classes derived from
            Internet conceptual table entries which augment other
            Internet conceptual table entries shall be bound to the
            table entry object class that they augment.
     
            The structure of the naming tree is illustrated below.
     
     
     
            LaBarre             Expires August, 1994             Page 39
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
             Note: The system object class may be bound to objects other
                   than root.
     
            "CCITT Rec. X.660 | ISO/IEC 98344-1 : 1992": root
                 |
                 |-- "Rec. X.721 | ISO/IEC 10165-2 : 1992" : system
                      |
                      |-- group derived object class
                      |
                      |-- group derived object class
                      |         |-- table entry
                      |              |-- augmentation of table entry
                      |
                      |-- group derived object class
                      |
                      | . . .
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994             Page 40
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            The naming tree for the Internet MIB-II derived object
            classes [22] is illustrated below.
     
            "CCITT Rec. X.660 | ISO/IEC 9834-1 : 1992":root
            |
            |-- "Rec. X.721 | ISO/IEC 10165-2 : 1992":system
                 |
                 |-- {iimcRFC12131354}:internetSystem
                 |
                 |-- {iimcRFC12131354}:at --- {iimcRFC12131354}:atEntry
                 |
                 |-- {iimcRFC12131354}:egp ---{iimcRFC12131354}:egpNeighEntry
                 |
                 |-- {iimcRFC12131354}:icmp
                 |
                 |-- {iimcRFC12131354}:interfaces --- {iimcRFC12131354}:ifEntry
                 |
                 |-- {iimcRFC12131354}:ip
                 |     |--- {iimcRFC12131354}:ipRouteEntry
                 |     |--- {iimcRFC12131354}:ipAddrEntry
                 |     |--- {iimcRFC12131354}:ipNetToMediaEntry
                 |     |--- {iimcRFC12131354}:ipForwardEntry
                 |
                 |-- {iimcRFC12131354}:snmp
                 |
                 |-- {iimcRFC12131354}:tcp --- {iimcRFC12131354}:tcpConnEntry
                 |
                 |-- {iimcRFC12131354}:udp --- {iimcRFC12131354}:udpEntry
     
     
            3.3.3 Attribute Property-label Changes
     
            OSI naming attributes are constrained to be GET only since
            the name of the object cannot change during its lifetime.
            Since the name is derived from the values of the Internet
            objects used for indexing conceptual table entries, the
            attributes derived from those indexing objects shall not be
            modified after the table entry object has been created.
     
            For managed object classes that have been derived from
            Internet conceptual rows, ensure that the property-label of
            the attributes derived from the Internet objects used for
            naming have the GET property-label. The attributes may be
            identified by the INDEX construct of the scannable notation
            used in the behaviour clause associated with the template.
     
     
            3.3.4 Post-processing of ASN.1 Module
     
            The syntax specific to each of the naming attributes must be
            inserted into the ASN.1 module. Insert into the ASN.1 module
            the syntax and type references appropriate for the all
            naming attributes, as derived according to the procedures in
            2.2.1, for referencing by templates for naming attributes.
     
            LaBarre             Expires August, 1994             Page 41
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            The syntax shall be of the form specified in 2.2.1. The
            label associated with the syntax shall be of the form <class
            label> || "IdValue".
     
            It may be possible to collapse repeated ASN.1 type
            references into a single common type reference, if desired.
            Several commonly-used ASN.1 type references (e.g.,
            Integer64k, Integer128, ObjectIdentifier) are defined by the
            IimcCommonDef ASN.1 module specified in 4.2, and may be
            IMPORTed into translated MIB ASN.1 modules when appropriate.
            However, care must be taken to ensure that any new common
            type reference labels are appropriately reflected in
            templates.
     
     
            3.3.5 Templates for Naming Attributes
     
            Naming attributes shall be defined for each object class as
            described in 2.2.1, and included as part of the object class
            templates in 3.2. The templates shall be of the form:
     
            <class label> || "Id" ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX
                 <module identification>|| "." || <class label> ||
                 "IdValue";
                 MATCHES FOR EQUALITY;;
                 BEHAVIOUR
                      <class label> || "Id"  || "Behaviour" BEHAVIOUR
                      DEFINED AS
                      !The naming attribute for object class <class
                      label>!;;
            REGISTERED AS {iimcAutoName <internetEntityId>(c)};
     
            where the following definitions apply.
     
            <module identification> -- The label of the ASN.1 module
            that contains the ASN.1 syntax being referenced. The module
            must appear in the document that defines the translated MIB.
            It must contain the ASN.1 syntax appropriate for the naming
            attribute, as specified in 2.2.1, and associated with the
            label <class label> || "IdValue".
     
            <class label> -- The label of the class for which the naming
            attribute is being defined.
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994             Page 42
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            3.3.6 Generation of MOCS
     
            A MOCS proforma shall be generated according to the format
            specified by [10]. All information shall be derived directly from
            the GDMO MIB except for the "set by create" column in attribute
            tables. The "set by create" column is "m" for all attributes which
            are GET- REPLACE [ADD-REMOVE]. The "set by create" column is "x"
            for all attributes which are GET only.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994             Page 43
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
                                4. IIMCIMIBTRANS MIB
     
            The GDMO templates and ASN.1 modules are included here in
            one section to facilitate automated processing. Comments and
            subsection headers are included in the form of ASN.1
            comments, i.e., preceded by "--".
     
            This document (IIMCIMIBTRANS) is allocated the following
            registration identifier for purposes of referencing material
            contained herein.
     
              iimcIIMCIMIBTRANS OBJECT IDENTIFIER ::={ iimcDocument 1 }
     
     
     
            -- 4.1 IMIBTRANS MIB GDMO TEMPLATES
     
     
            -- 4.1.1 IMIBTRANS Managed Object Classes
     
            internetAlarmRecord MANAGED OBJECT CLASS
                 DERIVED FROM
                 "Rec. X.721 | ISO/IEC 10165-2 : 1992":logRecord;
                 CHARACTERIZED BY
                 internetAlarmRecordPkg PACKAGE
                      BEHAVIOUR
                      internetAlarmRecordBehaviour BEHAVIOUR
                           DEFINED AS !This managed object is used to
                           represent logged information that resulted
                           from internetAlarm notifications or event
                           reports.!;;
                      ATTRIBUTES
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      probableCause GET;;;
     
                 CONDITIONAL PACKAGES
     
                 attributeIdentifierListPkg    PACKAGE
                      ATTRIBUTES
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      attributeIdentifierList GET;
                 REGISTERED AS {iimcPackage 1};
                 PRESENT IF
                      !The attributeIdentifierList parameter is present
                      in the internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!,
     
                 objectInstanceListPkg PACKAGE
                      ATTRIBUTES
                      objectInstanceList GET;
     
            LaBarre             Expires August, 1994             Page 44
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                 REGISTERED AS {iimcPackage 2};
                 PRESENT IF
                      !The objectInstanceList parameter is present in
                      the internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!,
     
                 perceivedSeverityPkg PACKAGE
                      ATTRIBUTES
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      perceivedSeverity GET;
                 REGISTERED AS {iimcPackage 3};
                      PRESENT IF !The perceivedSeverity parameter is
                      present in the internetAlarm notification or event
                      report corresponding to the instance of the
                      internet alarm record.!,
     
                 notificationIdPkg PACKAGE
                      ATTRIBUTES
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      notificationIdentifier GET;
                 REGISTERED AS {iimcPackage 4};
                 PRESENT IF
                      !The notificationId parameter is present in the
                      internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!,
     
                 correlatedNotPkg PACKAGE
                      ATTRIBUTES
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      correlatedNotifications GET;
                 REGISTERED AS {iimcPackage 5};
                 PRESENT IF
                      !The correlatedNot parameter is present in the
                      internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!,
     
                 transportDomainPkg PACKAGE
                      ATTRIBUTES
                      transportDomain GET;
                 REGISTERED AS {iimcPackage 6};
                 PRESENT IF
                      !The transportDomain parameter is present in the
                      internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!,
     
                 transportAddressPkg PACKAGE
                      ATTRIBUTES
                      transportAddress GET;
                 REGISTERED AS {iimcPackage 7};
                 PRESENT IF
     
            LaBarre             Expires August, 1994             Page 45
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                      !The transportAddress parameter is present in the
                      internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!,
     
                 accessControlInfoPkg PACKAGE
                      ATTRIBUTES
                      accessControlInfo GET;
                 REGISTERED AS {iimcPackage 8};
                 PRESENT IF
                      !The accessControlInfo parameter is present in the
                      internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!,
     
                 additionalInformationPkg PACKAGE
                      ATTRIBUTES
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      additionalInformation GET;
                 REGISTERED AS {iimcPackage 9};
                 PRESENT IF
                      !The additionalInformation parameter is present in
                      the internetAlarm notification or event report
                      corresponding to the instance of the internet
                      alarm record.!;
            REGISTERED AS {iimcObjectClass 1};
     
     
            -- 4.1.2 IMIBTRANS Attribute Types
     
            -- The following ISO/CCITT attribute types, listed in
            -- alphabetical order, are derived from Internet
            -- attribute types to facilitate Internet MIB translation.
            -- Other attributes may be derived from these
            -- types.
     
            autonomousType ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.AutonomousType;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      autonomousTypeBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!Represents an independently extensible type
                           identification value. It may, for example,
                           indicate a particular sub-tree with further
                           MIB definitions, or define a particular type
                           of protocol or hardware.!!;
                      ENDPARSE!;;;
     
     
            LaBarre             Expires August, 1994             Page 46
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            counter32 ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.Counter32;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      counter32Behaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [17] by the same name.!!;
                      ENDPARSE!;;;
     
            counter64 ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.Counter64;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      counter64Behaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [17] by the same name.!!;
                      ENDPARSE!;;;
     
            dateAndTime ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.DateAndTime;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      dateAndTimeBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                      !!A date-time specification.
                      field     octets contents          range
                      -----     ------ --------          -----
                      1    1-2  year                     0..65536
                      2    3    month                    1..12
                      3    4    day                      1..31
                      4    5    hour                     0..23
                      5    6    minutes                  0..59
                      6    7    seconds                  0..60
                      (use 60 for leap-second)
                      7    8    deci-seconds             0..9
                      8    9    direction from UT        "+"/ "-"
                      9    10   hours from UT            0..11
                      10   11   minutes from UT          0..59
     
                           For example, Tuesday May 26, 1992 at 1:30:15
                           PM EDT would be displayed as: 1992-5-
                           26,13:30:15.0,-4:0
     
     
            LaBarre             Expires August, 1994             Page 47
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                           Note that if only local time is known, then
                           timezone information (fields 8-10) is not
                           present.!!;
                      DISPLAY-HINT !!2d-1d-1d,1d:1d:1d.1d,1a1d:1d!!;
                      ENDPARSE!;;;
     
            displayString ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.DisplayString;
                 MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;
                 BEHAVIOUR
                      displayStringBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!Represents textual information taken from
                           the NVT ASCII character set, as defined in
                           pages 4, 10-11 of RFC 854. Any object defined
                           using this syntax shall not exceed 255
                           characters in length.!!;
                      DISPLAY-HINT !!255a!!;
                      ENDPARSE!;;;
     
            gauge32 ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.Gauge32;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      gauge32Behaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [17] by the same name.!!;
                      ENDPARSE!;;;
     
            instancePointer ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.InstancePointer;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      instancePointerBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!A pointer to a specific instance of a
                           conceptual row of a MIB table in the managed
                           device. By convention, it is the name of the
                           particular instance of the first columnar
                           object in the conceptual row.!!;
                      ENDPARSE!;;;
     
            LaBarre             Expires August, 1994             Page 48
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
            ipAddress ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.IpAddress;
                 MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;
                 BEHAVIOUR
                      ipAddressBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!This attribute represents a 32-bit internet
                           address. It is represented as an octet string
                           of length 4, in network Byte-order.!!;
                      ENDPARSE!;;;
     
            macAddress ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.MacAddress;
                 MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;
                 BEHAVIOUR
                      macAddressBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!Represents an 802 MAC address represented
                           in the `canonical' order defined by IEEE
                           802.1a, i.e., as if it were transmitted least
                           significant bit first, even though 802.5 (in
                           contrast to other 802.x protocols) requires
                           MAC addresses to be transmitted most
                           significant bit first.!!;
                      DISPLAY-HINT !!1x:!!;
                      ENDPARSE!;;;
     
            nsapAddress ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.NsapAddress;
                 MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;
                 BEHAVIOUR
                      nsapAddressBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [17] by the same name.!!;
                      DESCRIPTION
                           !!This attribute represents an ISO/CCITT
                           network address. It is length octet string.
                           The first octet of the string contains a
                           binary value, in the range of 0..20, and
                           indicates the length in octets of the NSAP.
     
            LaBarre             Expires August, 1994             Page 49
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                           Following the first octet, is the NSAP
                           expressed in concrete binary notation,
                           starting with the most significant octet. A
                           zero-length NSAP is used as a "special"
                           address, meaning "the default NSAP"
                           (analogous to the IP address 0.0.0.0). Such
                           an NSAP is encoded as a single octet
                           containing the value 0. All other NSAPS are
                           encoded in at least 4 octets.!!;
                      ENDPARSE!;;;
     
            opaque ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.Opaque;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      opaqueBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [17] by the same name.!!;
                      DESCRIPTION
                           !!This attribute represents arbitrary ASN.1
                           syntax. A value is encoded using the Basic
                           Encoding Rules [3] into a string of octets.
                           This, in turn, is encoded as an OCTET STRING,
                           in effect "double-wrapping" the original
                           ASN.1 value.!!;
                      ENDPARSE!;;;
     
            physAddress ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.PhysAddress;
                 MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;
                 BEHAVIOUR
                      physAddressBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!Represents media- or physical-level
                           addresses.!!;
                      DISPLAY-HINT !!1x:!!;
                      ENDPARSE!;;;
     
            rowStatus ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.RowStatus;
                 MATCHES FOR EQUALITY;
                 BEHAVIOUR
                      rowStatusBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
     
            LaBarre             Expires August, 1994             Page 50
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!The RowStatus attribute is used by SNMP to
                           manage the creation and deletion of
                           conceptual rows, and is used as the value of
                           the SYNTAX clause for the conceptual row
                           status column.
     
                           Creation and deletion of object classes
                           derived from conceptual rows shall only be
                           via the CMIS M-CREATE and M-DELETE services.
     
                           The rowStatus attribute has two valid values:
     
                           *  `active', which indicates that the
                              conceptual row is available for use by the
                              managed device;
     
                           *  `notInService', which indicates that the
                              conceptual row exists in the agent, but is
                              unavailable for use by the managed device.
     
                           When used in conjunction with a CMIS M-CREATE
                           request, the rowStatus attribute shall
                           indicate whether the entry shall be created
                           in the "active" state, or the "notInService"
                           state.
     
                           When retrieved, the rowStatus attribute shall
                           only return one of the two values described
                           above.
     
                           When used in a SET operation, the rowStatus
                           attribute shall only assume one of the two
                           values described above.!!;
                      ENDPARSE!;;;
     
            testAndIncr ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.TestAndIncr;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      testAndIncrBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!Represents integer-valued information used
                           for atomic operations. When the management
                           protocol is used to specify that an object
                           instance having this syntax is to be
                           modified, the new value supplied via the
     
            LaBarre             Expires August, 1994             Page 51
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                           management protocol must precisely match the
                           value presently held by the instance. If not,
                           the management protocol set operation fails
                           with an error of `inconsistentValue'.
                           Otherwise, if the current value is the
                           maximum value of 2^31-1 (2147483647 decimal),
                           then the value held by the instance is
                           wrapped to zero; otherwise, the value held by
                           the instance is incremented by one. (Note
                           that regardless of whether the management
                           protocol set operation succeeds, the previous
                           value held by the instance is returned.)
     
                           The value of the ACCESS clause for objects
                           having this syntax is either `read-write' or
                           `read-create'. When an instance of a columnar
                           object having this syntax is created, any
                           value may be supplied via the management
                           protocol.!!;
                      ENDPARSE!;;;
     
            timeInterval ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.TimeInterval;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      timeIntervalBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!A period of time, measured in units of 0.01
                           seconds.!!;
                      ENDPARSE!;;;
     
            timeStamp ATTRIBUTE
                 DERIVED FROM timeTicks;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      timeStampBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!The value of MIB-II's sysUpTime object at
                           which specific occurrence happened. The
                           specific occurrence must be defined in the
                           description of any object defined using this
                           type.!!;
                      ENDPARSE!;;;
     
     
            LaBarre             Expires August, 1994             Page 52
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            timeTicks ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.TimeTicks;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      timeTicksBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!This attribute type represents a non-
                           negative integer which represents the time,
                           modulo 2->32 (4294967296 decimal), in
                           hundredths of a second between two epochs.
                           When attributes are defined which use this
                           attribute type, the description of the object
                           identifies both of the reference epochs.!!;
                      ENDPARSE!;;;
     
            truthValue ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.TruthValue;
                 MATCHES FOR EQUALITY;
                 BEHAVIOUR
                      truthValueBehaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION !!Represents a boolean value.!!;
                      ENDPARSE!;;;
     
            uInteger32 ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.UInteger32;
                 MATCHES FOR EQUALITY, ORDERING;
                 BEHAVIOUR
                      uInteger32Behaviour BEHAVIOUR
                      DEFINED AS
                      !BEGINPARSE
                      REFERENCE
                           !!This corresponds to the type defined in
                           [18] by the same name.!!;
                      DESCRIPTION
                           !!As defined for the ASN.1 Built-in INTEGER
                           type. Only the value range constraint
                           (0..4294967295) is added.!!;
                      ENDPARSE!;;;
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994             Page 53
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            -- 4.1.3 IMIBTRANS Attributes
     
     
            accessControlInfo ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.AccessControlInfo;
                 MATCHES FOR EQUALITY;
                 BEHAVIOUR
                      accessControlInfoBehaviour BEHAVIOUR
                      DEFINED AS
                      !This attribute is used for filtering on the access
                      control information associated with
                      internetAlarms.!;;
            REGISTERED AS {iimcAttribute 1};
     
            internetTrapInfo ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.InternetTrapInfo;
                 BEHAVIOUR
                      internetTrapInfoBehaviour BEHAVIOUR
                      DEFINED AS
                      !This attribute is used for filtering on the
                      internetTrapInfo field associated with
                      internetAlarms.!;;
            REGISTERED AS {iimcAttribute 2};
     
            objectInstanceList ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.ObjectInstanceList;
                 MATCHES FOR EQUALITY, SET-COMPARISON, SET-INTERSECTION;
                 BEHAVIOUR
                      objectInstanceListBehaviour BEHAVIOUR
                      DEFINED AS
                      !This attribute is used for filtering on the object
                      instances associated with internetAlarms.!;;
            REGISTERED AS {iimcAttribute 3};
     
            transportAddress ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.TransportAddress;
                 MATCHES FOR EQUALITY, SUBSTRINGS;
                 BEHAVIOUR
                      transportAddressBehaviour BEHAVIOUR
                      DEFINED AS
                      !The transport service address by which the party
                      receives network management traffic, formatted
                      according to the corresponding value of
                      transportDomain. For snmpUDPDomain, transportAddress
                      is formatted as a 4-octet IP Address concatenated
                      with a 2-octet UDP port number.!;;
            REGISTERED AS {iimcAttribute 4};
     
            transportDomain ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.TransportDomain;
                 MATCHES FOR EQUALITY;
                 BEHAVIOUR
                      transportDomainBehaviour BEHAVIOUR
                      DEFINED AS
     
            LaBarre             Expires August, 1994             Page 54
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                      !Indicates the kind of transport service by which
                      the party receives network management traffic. An
                      example of a transport domain is 'snmpUDPDomain'
                      (SNMP over UDP).!;;
            REGISTERED AS {iimcAttribute 5};
     
            unknownVarBindList ATTRIBUTE
                 WITH ATTRIBUTE SYNTAX IimcCommonDef.UnknownVarBindList;
                 BEHAVIOUR
                      unknownVarBindListBehaviour BEHAVIOUR
                      DEFINED AS
                      !This attribute is used for filtering on the
                      unknownVarBindList field associated with
                      internetAlarms.!;;
            REGISTERED AS {iimcAttribute 6};
     
     
            -- 4.1.4 IMIBTRANS Notifications
     
            internetAlarm NOTIFICATION
                      BEHAVIOUR
                      internetAlarmBehaviour BEHAVIOUR
                      DEFINED AS
                      !This is a generic notification for translated
                      Internet SNMPv1 traps and SNMPv2 notifications.
     
                      The attributeIdentifierList, and
                      objectInstanceList fields contain information
                      which may be duplicated in other fields. They are
                      included to facilitate filtering of notifications
                      on the basis of contained attributes and the
                      object instances to which the notification may
                      pertain.
     
                      The probableCause field shall contain the
                      snmpTrapOID as derived in clause 2.1.2. This
                      uniquely distinguishes SNMP traps and may be used
                      for filtering. Only the "globalValue", i.e., OID,
                      form of the probableCause syntax shall be used.
     
                      The attributeIdentifierList field shall contain
                      the attribute identifiers for the attributes
                      derived from the varBind components of the SNMP
                      variable-
                      bindings list. This field is optional.
     
                      The objectInstanceList field shall contain the
                      object instances associated with the attributes
                      derived from the varBind components of the SNMP
                      variable-bindings list. This field is optional.
     
                      The internetTrapInfo field shall contain the
                      attributes and their values, and optionally their
                      associated object instances, as derived from the
     
            LaBarre             Expires August, 1994             Page 55
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                      varBind components of the SNMP variable-bindings
                      list. This field is optional.
     
                      The unknownVarBindList shall consist of the
                      sequence of varBinds contained in the variable-
                      bindings list for which translation was not
                      possible, i.e., the attribute OID and object
                      instance information could not be determined. This
                      field is optional.
     
                      The perceivedSeverity, notificationIdentifier, and
                      correlatedNotification field semantics are as
                      defined in [6], and the syntax is as defined in
                      [8]. These fields are optional.
     
                      The transportDomain field shall contain the OID
                      for the transport protocol associated with the
                      Internet agent that sent the alarm. This field is
                      optional.
     
                      The transportAddress field shall contain the
                      transport layer address that the Internet agent
                      used to send the SNMP trap/notification. The
                      format of the field shall be in accordance with
                      the transportDomain format. This field is
                      optional.
     
                      The accessControlInfo field shall contain the
                      access control information associated with the
                      trap/notification, i.e., either the community
                      string or the party information. This field is
                      optional.
     
                      The additionalInformation field shall contain any
                      additional information that may be associated with
                      the notification.!;;
                 WITH INFORMATION SYNTAX IimcCommonDef.InternetAlarmInfo
                 AND ATTRIBUTE IDS
                 probableCause
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      probableCause,
                 attributeIdList
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      attributeIdentifierList,
                 objectInstanceList  objectInstanceList,
                 unknownVarBindList  unknownVarBindList,
                 internetTrapInfo    internetTrapInfo,
                 perceivedSeverity
                      "Rec. X.721 | ISO/IEC 10165-2 :1992":
                      perceivedSeverity,
                 notificationId
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      notificationIdentifier,
                 correlatedNot
     
            LaBarre             Expires August, 1994             Page 56
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      correlatedNotifications,
                 transportDomain     transportDomain,
                 transportAddress    transportAddress,
                 accessControlInfo   accessControlInfo,
                 additionalInformation
                      "Rec. X.721 | ISO/IEC 10165-2 : 1992":
                      additionalInformation;
            REGISTERED AS {iimcNotification 1};
     
     
     
            -- 4.2 IMIBTRANS ASN.1 MODULES
     
            IimcAssignedOIDs
            {iso(1) member-body(2) 124 forum(360501) iimcManual(15)
            iimcModule(0) 1}
            DEFINITIONS ::= BEGIN
     
     
     
     
            -- The following object identifiers are assigned for IIMC
            -- use by the NM Forum
     
            iimcAutoTrans  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            124 forum(360501) 14 }
            iimcManual     OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            124 forum(360501) 15 }
     
            -- The following object identifiers are assigned for
            -- registering MIB elements generated using the translation
            -- procedures defined by this document. For example,
            -- these arcs are used by the translated MIB-II [22] and
            -- translated Party MIB [24].
            -- Refer to section 2.1.1 of this document for instructions
            -- on use of these arcs.
     
            iimcAutoModule      OBJECT IDENTIFIER ::= { iimcAutoTrans 0
            }
            iimcAutoObjAndAttr       OBJECT IDENTIFIER ::= {
            iimcAutoTrans 1 }
            iimcAutoNameBinding      OBJECT IDENTIFIER ::= {
            iimcAutoTrans 4 }
            iimcAutoDocument         OBJECT IDENTIFIER ::= {
            iimcAutoTrans 13 }
            iimcAutoName             OBJECT IDENTIFIER ::= {
            iimcAutoTrans 15 }
     
            -- The following object identifiers are assigned for manual
            -- registration of MIB elements specified by IIMC documents.
            -- These arcs are used to register IIMC documents and the
            -- common MIB elements defined by this document, the Proxy
            -- MIB defined by [23], the ACL MIB defined by [24], and the
     
            LaBarre             Expires August, 1994             Page 57
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            -- omibtransSpt MIB defined by [25].
            -- Refer to section 2.1.2 of this document for description
            -- of the use of these arcs.
     
            iimcModule          OBJECT IDENTIFIER ::= { iimcManual 0 }
            iimcAttribute       OBJECT IDENTIFIER ::= { iimcManual 1 }
            iimcObjectClass     OBJECT IDENTIFIER ::= { iimcManual 3 }
            iimcNameBinding     OBJECT IDENTIFIER ::= { iimcManual 4 }
            iimcNotification    OBJECT IDENTIFIER ::= { iimcManual 5 }
            iimcParameter       OBJECT IDENTIFIER ::= { iimcManual 9 }
            iimcPackage         OBJECT IDENTIFIER ::= { iimcManual 10 }
            iimcDocument        OBJECT IDENTIFIER ::= { iimcManual 13 }
            iimcExtension       OBJECT IDENTIFIER ::= { iimcManual 14 }
     
            -- The following object identifiers are assigned to register
            -- IIMC documents.
     
            iimcIIMCIMIBTRANS   OBJECT IDENTIFIER ::= {iimcDocument 1}
            iimcIIMCProxy       OBJECT IDENTIFIER ::= {iimcDocument 3}
            iimcIIMCACLMIB      OBJECT IDENTIFIER ::= {iimcDocument 4}
            iimcIIMCOMIBTRANS   OBJECT IDENTIFIER ::= {iimcDocument 5}
     
            END
     
     
            IimcCommonDef
            {iso(1) member-body(2) 124 forum(360501) iimcManual(15)
            iimcModule(0) 2}
            DEFINITIONS IMPLICIT TAGS ::= BEGIN
            IMPORTS
                 AdditionalInformation, ProbableCause,
                 PerceivedSeverity, NotificationIdentifier,
                 CorrelatedNotifications, AttributeIdentifierList
                      FROM Attribute-ASN1Module {joint-iso-ccitt ms(9)
            smi(3)
                      part2(2) asn1Module(2) 1}
                 Attribute, ObjectInstance
                      FROM CMIP-1 {joint-iso-ccitt ms(9) cmip(1)
            version(1) protocol(3)}
                 Counter32, Counter64, NsapAddress, IpAddress,
                 UInteger32, Gauge32, Opaque, TimeTicks, Integer32
                      FROM SNMPv2-SMI
                 TEXTUAL-CONVENTION, DateAndTime, DisplayString,
                 PhysAddress, MacAddress, TruthValue, TestAndIncr,
                 AutonomousType, InstancePointer, TimeStamp,
                 TimeInterval
                      FROM SNMPv2-TC;
     
            AccessControlInfo ::= CHOICE  {
                 communityString     [0] OCTET STRING,
                 partyInfo      [1] SEQUENCE   {
                                          srcParty OBJECT IDENTIFIER,
                                          dstparty OBJECT IDENTIFIER,
                                          context   OBJECT IDENTIFIER
     
            LaBarre             Expires August, 1994             Page 58
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
                                          }
                                }
     
            Integer ::= INTEGER
     
            Integer128 ::= INTEGER (0..127)
     
            Integer64k ::= INTEGER (0..65535)
     
            InternetAlarmInfo ::= SEQUENCE     {
                 probableCause         ProbableCause,
                 attributeIdList          [1] AttributeIdentifierList
            OPTIONAL,
                 objectInstanceList  [2] ObjectInstanceList OPTIONAL,
                 unknownVarBindList  UnknownVarBindList OPTIONAL,
                 internetTrapInfo         [5] InternetTrapInfo OPTIONAL,
                 perceivedSeverity   [6] PerceivedSeverity OPTIONAL,
                 notificationId      [7] NotificationIdentifier
            OPTIONAL,
                 correlatedNot       [8] CorrelatedNotifications
            OPTIONAL,
                 transportDomain     [9] TransportDomain OPTIONAL,
                 transportAddress    [10] TransportAddress OPTIONAL,
                 accessControlInfo   [11] AccessControlInfo OPTIONAL,
                 additionalInformation    [12] AdditionalInformation
            OPTIONAL
                 }
     
            InternetTrapInfo ::= SET OF SEQUENCE {
                 objectInstance ObjectInstance OPTIONAL,
                 COMPONENTS OF Attribute}
     
            ObjectIdentifier ::= OBJECT IDENTIFIER
     
            ObjectInstanceList ::= SET OF ObjectInstance
     
            OctetString ::= OCTET STRING
     
            RowStatus ::=  INTEGER   {
                      -- the following two values are states:
                      active(1),
                      notInService(2)
                      }
     
            TransportAddress ::= OCTET STRING
     
            TransportDomain ::= OBJECT IDENTIFIER
     
            UnknownVarBindList ::= CHOICE {
                      v1        [3] RFC1157-SNMP.VarBindList,
                      v2        [4] SNMPv2-PDU.VarBindList
                                }
     
            END
     
            LaBarre             Expires August, 1994             Page 59
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
                            5. COMPLIANCE AND CONFORMANCE
     
     
     
            5.1 COMPLIANCE
     
            An Internet MIB translated into ISO/CCITT GDMO format in
            compliance with this specification shall:
     
            (a)  be registered in accordance with the procedures
              specified by section 2.1,
     
            (b)  comply with the naming approach specified by section
              2.2,
     
            (c)  contain object identifiers derived in accordance with
              the procedures specified by section 2.3,
     
            (d)  comply with the inheritance hierarchy specified by
              section 2.4,
     
            (e)  contain GDMO templates labeled in accordance with the
              convention specified by section 2.5,
     
            (f)  comply with the pre-translation procedures specified by
              section 3.1,
     
            (g)  contain GDMO templates derived in accordance with the
              templates and procedures specified by section 3.2, and
     
            (h)  comply with post-translation procedures specified by
              (at minimum) sections 3.3.1-3.3.3 and 3.3.5-3.3.6.
              Deviations permitted by clause 3.3.2 shall be documented
              in a System Conformance Statement as shown in Annex A.
     
     
     
            5.2 CONFORMANCE
     
            An implementation claiming conformance to a translated ISO/CCITT
            GDMO MIB shall conform to the all of the requirements stated in
            the corresponding MOCS proforma (generated according to the
            procedure specified by section 3.3.6).
     
            An implementation claiming conformance to any IMIBTRANS GDMO
            templates or ASN.1 types specified in section 4 shall
            conform to the requirements stated in the corresponding MOCS
            proforma templates specified by Annex A.
     
     
     
     
            LaBarre             Expires August, 1994             Page 60
     
     
     DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
          ANNEX A (NORMATIVE): MANAGED OBJECT CONFORMANCE STATEMENTS (MOCS)
     
     
                  This section available only in Postscript Format.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     LaBarre             Expires August, 1994            Page A-1
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
                                  ANNEX B: GLOSSARY
     
            ASN.1   Abstract Syntax Notation One
            CCITT   Consultative Committee on Telephony and Telegraphy
            CMIP    Common Management Information Protocol
            CMIS    Common Management Information Service
            DN      Distinguished Name
            GDMO    Guidelines for the Definition of Managed Objects
            GNMP    Government Network Management Profile
            IIMC    ISO/CCITT and Internet Management Coexistence
            ISO     International Standards Organization
            MIB     Management Information Base
            MOCS    Managed Object Conformance Statement
            NMF     Network Management Forum
            OID     Object Identifier
            OSI     Open Systems Interconnection
            PDU     Protocol Data Unit
            RDN     Relative Distinguished Name
            RFC     Request For Comments
            SMI     Structure of Management Information
            SNMP    Simple Network Management Protocol
            SNMPv1  Simple Network Management Protocol Version 1
            SNMPv2  Simple Network Management Protocol Version 2
            TCP/IP  Transmission Control Protocol/Internetwork Protocol
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994            Page B-1
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
     
     
                                 ANNEX C: REFERENCES
     
            1) CCITT Recommendation X.700, Management Framework
               Definition for Open Systems Interconnection (OSI).
     
               ISO/IEC 7498-4: 1989, Information Processing Systems --
               Open Systems Interconnection -Basic Reference Model Part
               4 -- Management Framework.
     
            2) ISO/IEC 8824: Information Technology -- Open System
               Interconnection -- Specification of Abstract Syntax
               Notation One (ASN.1),1990.
     
            3) CCITT Recommendation X.209 (1988), Specification of basic
               encoding rules for abstract syntax notation one (ASN.1).
     
               ISO/IEC 8825: 1990, Information Technology -- Open System
               Interconnection -- Specification of Basic Encoding Rules
               for Abstract Syntax Notation One (ASN.1).
     
            4) CCITT Recommendation X.710, (1991), Common Management
               Information Service Definition for CCITT Applications.
     
               ISO/IEC 9595: 1991, Information Technology -- Open System
               Interconnection -- Common Management Information Service
               Definition.
     
            5) CCITT Recommendation X.711 | ISO/IEC 9596-1: 1991,
               Information Technology -- Open Systems Interconnection --
               Common Management Information Protocol -- Part 1:
               Specification.
     
            6) CCITT Recommendation X.733 (1992) | ISO/IEC 10164-4:
               1992, Information Technology -- Open Systems
               Interconnection -- Systems Management -- Part 4: Alarm
               Reporting Function.
     
            7) CCITT Recommendation X.720 (1992) | ISO/IEC 10165-1:
               1992, Information Technology -- Open Systems
               Interconnection -- Structure of Management Information --
               Part 1: Management Information Model.
     
            8) CCITT Recommendation X.721 (1992) | ISO/IEC 10165-2:
               1992, Information Technology -- Open Systems
               Interconnection -- Structure of Management Information --
               Part 2: Definition of Management Information.
     
            9) CCITT Recommendation X.721 (1992) | ISO/IEC 10165-4:
               1992, Information Technology -- Open Systems
               Interconnection -- Structure of Management Information --
               Part 4: Guidelines for the Definition of Managed Objects.
     
            LaBarre             Expires August, 1994            Page C-1
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
     
            10)  CCITT Recommendation X.723 (1993) | ISO/IEC 10165-6:
               1993, Information Technology -- Open Systems
               Interconnection -- Structure of Management Information --
               Part 6: Requirements and Guidelines for Implementation
               Conformance Statement Proformas associated with OSI
               Management.
     
            11)  RFC1155, M. Rose and K. McCloghrie, Structure and
               Identification of Management Information for TCP/IP based
               internets, May 1990.
     
            12)  RFC1157, J.D. Case, M.S. Fedor, M.L. Schoffstall,C.
               Davin, Simple Network Management Protocol (SNMP), May
               1990.
     
            13)  RFC1212, M. Rose, K. McCloghrie -- Editors, Concise MIB
               Definitions, March 1991.
     
            14)  RFC1213, K. McCloghrie and M. Rose -- Editors,
               Management Information Base for Network Management of
               TCP/IP-based internets: MIB-II, March 1991.
     
            15)  RFC1215, M. Rose -- Editor, A convention for Defining
               Traps for use with the SNMP, March 1991.
     
            16)  RFC1441, J.D. Case, K. McCloghrie, M.T. Rose,
               S.L.Waldbusser, Introduction to version 2 of the
               Internet-standard Network Management Framework, April
               1993.
     
            17)  RFC1442, J.D. Case, K. McCloghrie, M.T. Rose,
               S.L.Waldbusser, Structure of Management Information for
               version 2 of the Simple Network Management Protocol
               (SNMPv2), April 1993.
     
            18)  RFC1443, J.D. Case, K. McCloghrie, M.T. Rose,
               S.L.Waldbusser, Textual Conventions for version 2 of the
               Simple Network Management Protocol (SNMPv2), April 1993.
     
            19)  RFC1448, J.D. Case, K. McCloghrie, M.T. Rose,
               S.L.Waldbusser, Protocol Operations for version 2 of the
               Simple Network Management Protocol (SNMPv2), April 1993.
     
            20)  RFC1450, J.D. Case, K. McCloghrie, M.T. Rose,
               S.L.Waldbusser, Management Information Base for version 2
               of the Simple Network Management Protocol (SNMPv2), April
               1993.
     
            21)  RFC1452, J.D. Case, K. McCloghrie, M.T. Rose,
               S.L.Waldbusser, Coexistence between version 1 and version
               2 of the Internet Network Management Framework, April
               1993.
     
     
            LaBarre             Expires August, 1994            Page C-2
     
     
            DRAFT      <draft-labarre-internetmib-iso-04.txt> February, 1994
     
     
            22)  Network Management Forum: Forum 029, Translation of
               Internet MIB-II (RFC 1213) to ISO/CCITT GDMO MIB, Issue
               1.0, October 1993.
     
            23)  Network Management Forum: Forum 028, ISO/CCITT to
               Internet Management Proxy, Issue 1.0, 1993.
     
            24)  Network Management Forum: Forum 027, ISO/CCITT to
               Internet Management Security, Issue 1.0, October 1993.
     
            25)  Network Management Forum: Forum 030, Translation of
               ISO/CCITT GDMO MIBs to Internet MIBs, Issue 1.0, October
               1993.
     
            26)  NM Forum and X/Open, ISO/CCITT and Internet Management:
               Coexistence and Interworking Strategy, Issue 1.0,
               October, 1992.
     
            27)  Federal Information Processing Standards Publication
               179 -- Government Network Management Profile v1.0,
               December 1992.
     
     
                        INTERNET DRAFT - EXPIRES AUGUST, 1994
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
            LaBarre             Expires August, 1994            Page C-3